VRU Routing Client - DTMF Label

[aceyuscco]

Very simple call flow. No Network VRU, just a basic Event Feed VRU. VRU makes route request to ICM. ICM returns a Label using a Dynamic Label Node of *8,12345. No issues whatsoever. However, if the Label has a prefix of DTMF (DTMF*8,12345) the Route Select event is never generated and an error code of 279 is shown in the PIM and OPC log. Below is the error in the OPC log. Anyone out there familiar with the Ged125 spec that may have run into this? Maybe a registry bit that can be flipped so it does NOT interrogate the label for a prefix of DTMF and simply treats it like any other label? 

14:31:54:058 PG2A-opc Trace: CSTA_ROUTE_END (PID=5012) - routingCrossRefID=29 errorValue(279)=TAKEBACK_N_XFER_ROUTE_END.
14:31:54:058 PG2A-opc Trace: ProcessNetTakeBacknXfer - Called with NULL call object for dialogue 29 - no action taken.

On a good call it's ROUTE_REQUEST>ROUTE_SELECT>ROUTE_END whereas on the 'bad' call with the DTMF prefixed label it's simply ROUTE_REQUEST followed by ROUTE_END.

I uploaded a screenshot of the basic test script. Nothing more than a Label returned. Nothing else in the callflow for the test.

[Senthil Kumar Sankar]

Hello,

Have you tried using a "Run External Script". Below is what i see in the CVP guide.

In your Unified ICM script,when using outpulse transfers with SIP calls,digits can only be outpulsed on a call that has already been established.This means that it is necessary to transfer the call to the VXML gateway with a run external script node before you can send the DTMF*8 label. The Unified ICM script cannot send the DTMF*8 label back to Unified CVP for the first connect message in the call because the call has not been answered at this point.The Unified CVP Call Server uses SIP INFO messages to send the digits to the gateway for outpulsing.

Are you using CVP here or something else? In the GED 125 guide it is mentioned as below.

If you are using different VRU other then CVP, you might need to see how that accepts the *8 Label sent by ICM

The Call Routing Interface is the means by which the VRU asks the ICM for instructions on how to route (transfer) a call.  The VRU supplies information about the call to be routed, and the ICM returns a label specifying how the call should be routed.  The label is a character string that encodes the instructions for routing the call.  How the routing instructions are encoded in the label is a matter of convention and may vary from one VRU to another.  For example, a label might consist of the digits necessary to outpulse to accomplish the desired transfer; or contain the name of a program or script to be executed to accomplish the transfer.

Regards,

Senthil Kumar

[aceyuscco]

This is a non CVP VRU and it does not manipulate the returned Label in any way, assuming we receive it. However, in this case we simply don't receive the Route Select event with the Label. Something with the DTMF prefix appears to cause a different behavior on how the VRU PG processes the transaction before sending to the VRU. If we remove DTMF text from the Label, we receive the proper Route Select and associated Label. I've even tried changing to the different VRU Types (1-10) to no avail. 

[Senthil Kumar Sankar]

Yes if the VRU PG receives a Label with DTMF*8 from Router, it would recognize the string "DTMF*8" string and perform the next action.

In your initial snippet, i see this as a problem, The NULL Call Object leads the issue. If the CALLID is -1 this may occur. You can share the PIM/OPC logs

ProcessNetTakeBacknXfer - Called with NULL call object for dialogue 29 - no action taken