Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Return Destination - Does't have caller´s number after the agent disconnects the call

Status
Not open for further replies.

fabiopmoura

Technical User
Oct 4, 2013
31
0
0
BR
Hi guys,

sorry for my english

I'm deploying an EP to perform satisfaction research on a client. For this I am using the feature "Return Destination" of the VDN, but after the call is disconnected by the agent the VDN of "Return Destination" does not receive the caller's information "Calling Number & Name NO-CPNumber NO-CPName" and Session Manager has received "F:anonymous@anonymous".

I already tried several settings "Allow VDN Override?" and "public-unknown-numbering", but the call arrives on the VDN of "Return Destination" already without the caller's number, I know this because I put to ANI on the vector of VDN of "Return Destination" and no longer have plus the number of the caller.

Can you help me solve this problem?

 
What if an internal caller dials the queue and gets the survey? Does an internal station's entry in the public or private table appear in the CM invite to SM/AAEP for the survey?

I am familiar with the feature 'return destination' but not with the specifics of using it for an after call survey. I would think that calling number is irrelevant and you should be worrying more about UCID or UUI or some other parameter. Calling party number doesn't identify the specific call that is being sent to the survey. For example, what if some customers of Best Buy all call in to ask about the tracking status of their order. Pretend the Best Buy agents call the Post Office to ask about the order they shipped. All the Best Buy agents would call out with the same CPN to the Post Office and the Post Office system would use the VDN Return Destination to route them to a survey. If 9 Best Buy people had a good experience and 1 had a bad experience and the survey was meant to identify which agent gave you good or bad service, I would have to think that there is some parameter beyond calling party number that the AAEP survey would need to use to distinguish callers. Or, even more simple, how would you do surveys on callers that present no number at all? Anonymous would be the 'correct' CPN in that case and you still wouldn't be able to have the survey tell what specific call or agent serviced the customer.
 
Kyle555, thanks for your attention!

I go answering your question: when the call is made internally, the phone number is normally sent.

The project was divided in two phases and in this first phase will not have integration with the company database, the customer will answer three questions with options of 5-9 and will be identified by the telephone number. In the next phase we will have integration with the database where will have UUI and identification by "CPF" or "CNPJ" (equivalent to "SSN" or "ENI" in Brazil).

I know it does not seem to be very functional, but do you think this might not work?

The pre-sales that designed the project, had the information of our customer, that his customers are known and well specified, so they can recognize them by the number of the caller.

See the image of the search result in the software that was developed to extract the reports:
 
 https://files.engineering.com/getfile.aspx?folder=30817c29-ea93-43ce-bce3-61f02741b691&file=c65079c0-cce3-492f-91bc-18a3b0f0ea31.jpg
Maybe you should try playing with the tandem-calling-party-number table. How a call is setup with public or private numbering can be complicated and maybe it's because you're setting up a private numbering call to AAEP but the caller's number is formatted as public that you have a problem.

Play with it and find ways to test different call flows to see if you can get what you want.

For example, can you have a number that instead of going to a VDN to a queue to an agent and to VDN return destination, could you instead have a number that on the 'incoming call handling' table gets translated to the AAEP survey number? That way you can test 'outside caller into CM' and 'out to AAEP' without any of the VDN stuff in the middle.

Do you have other things on your system with private numbering that could come into CM via SIP and out to AAEP? If you have Aura Messaging, maybe a silly little test is to have AAM 'notify me' via phone call when you get a new voicemail and the 'notify me' number of your mailbox is 'something that goes to CM and bounces right to AAEP survey' and you can see if the AAM pilot number appears as caller ID.

What does the VDN return destination route to? Is it to a vector with 'route-to' some number to AAR/AAEP? Maybe if you did that route-to to the ARS code+AAEP number and had it go through the ARS table, it might be able to send the public formatted number.

In CM, a trunk with numbering format public will always be used to set up public numbering. A trunk of type private can be used to set up public or private numbered calls - that's why your SM trunks are always of 'private' numbering format. If it's AAR that picks a route to that trunk, it will be private formatted. If it is ARS that picks that private-numbering trunk, then it can send the number with public formatting.

I feel like if you test different cases and find what does and what does not work that you'll probably find something to work with.
 
I have already tested several ways and it was in one of the attempts that I realized that the problem is before the SIP trunk with SM or in the AAR route, because I take a step to verify the ANI in the VDN vector of "Return to destination" and it ignores , that is, the CPN is lost during the care of the agent.

The entrance trunk of the calls is a trunk R2 diod
 
I'm not familiar with those trunks in particular.

What if the incoming trunk maps direct to the survey number? Maybe the original VDN handling the call is doing something to conceal the original caller's CPN
 
Kyle555,

it seems that someone here from the company where I work had already had this problem and to solve it was necessary to develop an application that monitors the one-x agent and collect the UCID and ANI to send to the IW, was sent to the development team now.

Thank you so much for the help!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top