URGENT! Stripping DNIS using a vector!!!

[Zowwie438]

Everyone,

I need some help in a bad way. Here is the deal:

1) We have a TSAPI app that gets an adj lnk request.
2) The DNIS of this call is 54116.
3) TSAPI app replies with a routeSelectInv of 54120.
4) The call is properly sent to 54120.
*No problems above... Here is the prob.

1) 54120 is another CTI app (a speech) server that is configured to play X or Z menus based on DNIS instead of line ringing deviceID.

2) This speech app says.. If DNIS is 54120, then play XYZ. That is great if you call 54120, or call an outside line that then does a vector route-to to 54120.

3) In the situation above however... The DNIS is preserved as it's supposed to be and since the call was routed and not transferred, the DNIS info didn't shift to OCI data.

4) So... When the call reaches 54120, the DNIS is not what they expected and they can't play the right menu to the human.

Urrrg...

So... Here is what I have to try and figure out how to do:
1) How can I create a vector and make 54120 think that 54120 is actuall my DNIS?

2) I can modify the original app to send the call to lets say... 54111 and then have 5411 go to vector 123 and then perform a route-to 54120? But wouldn't the DNIS still be preserved in that case when it reaches 54120? Or would the DNIS at that point read 54120 with a last redirect VDN of 5411?

I hope I explained that well enough. Please respond in king, and please do it fast.

Thanks,

--Zowwie

 

[CBB]

Can you use converse on passing 54120?

 

[Zowwie438]

CBB,

I am not sure what you are talking about? I am a TSAPI geek. Is "converse" a vector command?

If so... Where can I find a ref document from avaya that lists each vector command and an explanation of what it does?

If I can get that, it may help me better understand what commands will best assist me.

BTW... Thanks 4 the rapid response.

 

[CBB]

Are you routing the call to this system using a T1?

Converse on is a vector step where you pass a call to a skill and can pass two strings of information and the vector hold control of the call. The adjunct system can service the call then dial a converse return feature access code that is setup in the "change feature-access-codes" screen and pass the call back to the switch.
Not sure how it would work with TSAPI but this is the only way I know of to choose what DNIS to send to another system other than if you are using a trunk and route pattern.

 

[Zowwie438]

Yeah... Here is what I have:

54120 is a ACD Group for the speech server.
54120 diverts the call to a lower level analog T1 line, say 11234.

When the call first reached 54120, the speech app saw it's DNIS as being 54116 (where TSAPI routed the call from), this is where the adjunct resides.

However... The way speech decides what to play to the human at 11234 is based off of the DNIS.

So... If you dial 54120 directly, all works. But if a call is routed there, then it fails because the DNIS is different.

I have reviewed the converse-on command (thanks BTW!), but I can't find any documentation of it removing DNIS.

I did however read that 54120 (my acd) may be able to configure that as "override set to y/n". This may allow it to work with success since I think it is basically saying... Use the original VDN/DNIS, or use my own(myself as DNIS).

I will advise the group if I find a solution.

 

[CBB]

Not sure if it will fix your issue. If you want to try, in a vector use converson-on skill x (skill of speech server) passing 54120 and ANI (if you want to pass ANI)

 

[Zowwie438]

CBB,

Thanks! I did have a chance to speak to one of our PBX folks and they confirmed that there are several ACD Groups going to this speech box in question.

All of the other groups are set to override=Y and the one I am seeing issues with (that is reading original DNIS of the call) is set to "N".

Sounds simple... But I want to review my traces and make sure that is it.

Thanks for your help! I really appreicate it. If you every have any CTI questions, tserver questions or the like... Feel free to call on me.

 

[Zowwie438]

All,

I wanted to provide some resolution to my previous question that I myself posted. Since I have found a solution.

The issue above was that the end application at 54120 should have never utilized DNIS to figure out what message to play. DNIS is that of what the customer called.

To make a long story short... The application is configured with a ACD Hunt Group to send the call to a lower level analog T1 line. There, the application says... Ohh, that call is on DNIS BLA, so play message X.

In the case mentioned above, the DNIS is not what they expected. So it was broken.

The solution is:
1) The application should have utilized the TSAPI unsolicited data structure of cstaDelivered_t or cstaEstablished_t.

There.. They can find a data ref to delivered.lastRedirected.deviceID OR established.lastRedirected.deviceID.

2) Once they ref that data element... It will always be that of the ACD Hunt Group 54120 or any other hunt group that sent the call down to the lower level T1 analog line.

Yes... This will require a code change, but it's much better than trying to locate a hack to make it work.

Best wishes to all and thanks for those who replied.

--Zowwie