I need access to the original DNIS in my TSAPI application.

Usually when a call comes into Avaya CM, the call is re-directed using the options defined in inc-call-handling-trmnt page. Here the original DNIS is modified/replaced to match one of the internal destinations like VDN or Hunt extension. Therefore, the original DNIS is lost for good. I have a requirement where the original DNIS needs to be captured by my application. To make this happen, I should be able to set UUI to the original DNIS, preferably in the vector. But the original DNIS is already lost when it reaches the vector.

Is there any way I can retain the original DNIS long enough to save it into UUI?

You should be able to see the original DNIS, as it was before it was changed by inc-call-handling-trmnt, in the Called Number field in the TSAPI message. Note that this is the number that was sent to the Communication Manager. If the originating switch altered the number then these alterations will be included.

I do not know of any way you can inject it into UUI. Definitely, it cannot be done using TSAPI and, as you say, it does not seem to be available to the vector.

Martin

I found I can get the original DNIS by monitoring the VDN. That's a relief. But the end application still needs a key in UUI, which I can link it back to the original DNIS.

Since the monitoring app can get back UUI and original DNIS, I can make it available to the end application. But the end application has to use the key in the UUI to retrieve the DNIS.

How to set any random unique value into UUI in the vector, that I can use as key?

Is it possible to set UCID to UUI?

It is possible to inject data into UUI inside a vector. Have a look at this topic http://www.devconnectprogram.com/forums/posts/list/7436.page I think it may cover what you want to do. You should definitely have a look at the EAS Vectoring guide that John references.

Martin

Yes, I am aware of that. I am currently setting UUI to tod in the vector, which is not unique enough if two calls arrive in the same second. If I can set UUI to ucid, that would be great. But I don't see any option for that.

So if I understand this correctly when the end application gets the call it has a different UCID than the original call so it has no way to find DNIS when going to the monitoring app? Have you tried looking at the Original Call Information to see if the original UCID is there?

Can you explain the call flow (including both of your application interactions: monitoring app, end app) so that we get a better idea of what is happening, and then we can make a suggestion.

The monitoring app is a TSAPI client application that can monitor the VDN. The end application is SIP IVR that is connected to Avaya via SIP trunking. The IVR can view the SIP headers (which includes UUI), the monitor app can see the original DNIS and UCID. The only variable field both apps can see is UUI. If I can pass original DNIS in UUI or pass unique mapping key (UCID) in UUI, my purpose would be served.

I see two ways to handle this.

1. The monitoring application writes as much about the call as it can to a database. Then the SIP IVR will query that database when it gets a call based on information in the SIP headers.

2. The monitoring app uses adjunct routing. This requires an Advanced TSAPI license, and also requires the application to make the routing decisions. In this case the application would register with the VDN to be a routing server. In the vector you add an adjunct routing step followed by a wait step. When a call hits the vector then the CM will send a route request to your application. When the application selects a route it can also take the UCID and put it in UUI. Once the route selection is made then the call will go to the next leg of the call with UCID in the UUI. I would suggest making use of the TSAPI exerciser (as the monitoring application) to prove this out in your call scenario.

Thanks, I was hoping to avoid adjunct routing. I know it will work, but will add to the cost of the solution. My monitoring app does have adjunct routing ability, but there is no guarantee my customers will have Advanced TSAPI license.

The first option won't work, I have looked at every field supplied by TSAPI, and then the SIP header at the trunk. There is no unique enough key to match the calls. UUI has to carry the original DNIS info.

Looks like I have to tell Marketing that Advanced TSAPI is an extra dependency for this solution.