Page 1 of 2

Cell Phone session.telephone.ani not coming in

Posted: Mon Feb 19, 2007 10:50 am
by melsullivan
Hello,

We are trying to save the session.telephone.ani value from incoming calls, but it seems a lot of the time (especially for cell phones) this value is either blank or bogus.

For example:

When we call into (617) 712-3663 from cell phone with number 1-902-471-4116, the ani value comes up blank. If we call a land line from this cell phone, it shows up as "out of area, private". So this sort of makes sense.

But when we call into the same number from cell phone with number 613.875.9714, the ani value comes up as 613.223.0000 which we know is wrong. If we call a land line from this cell phone, it shows the correct number (875....)

Both numbers have called into the 617-712-3663 within the last 24 hours.

Is there anything we can do to get the correct number from the session variables?

Thanks,

Melanie Sullivan

Posted: Mon Feb 19, 2007 11:11 am
by melsullivan
Actually - here is where it gets interesting. When the cell phone (613...) called into the 617-712-3663 number directly, the ani came through unchanged. But when he called the 866-544-7253 number, it replaced the ani with the 223-0000 number.

So what could be going on here? The 3663 number redirects to 1-888-394-8123, the 544 number doesn't redirect to anything...

Thanks,

Melanie

Currently investigating IVR issue with ANI

Posted: Tue Feb 20, 2007 10:59 am
by support
We are currently investigating this IVR issue with our carrier to determine why the ANI replacement occured over the 800 number.

Posted: Wed Feb 21, 2007 9:46 am
by melsullivan
Thanks - we're eagerly awaiting a reply on this issue - we have some pretty upset customers over the problem right now so a quick reply would be appreciated.

Thanks!

Melanie Sullivan

Posted: Thu Mar 01, 2007 1:48 pm
by melsullivan
I still haven't heard back on this..what is the latest status?

Thanks!

Melanie Sullivan

IVR issue still needs to be resolved

Posted: Thu Mar 01, 2007 2:48 pm
by support
Melanie,

We are still working to find a solution to this IVR problem. We will provide an update when we have a better idea of when a solution will be put in place.

Regards,
Plum Support

Posted: Wed Mar 14, 2007 11:15 am
by melsullivan
Thanks...do you have any idea at all about time frames? Are we looking at days? Weeks? Months (heaven forbid!)

Please let us know, we've got several deals hinging on this specific functionality.

Also, are there any workaround at all that we could put in the code? Redirecting phone numbers? anything?

Thanks,

Melanie Sullivan

IVR system received patch to help resolve caller id issues

Posted: Wed Mar 14, 2007 11:48 am
by support
Melanie,

We deployed a patch to our IVR systems early last week that should resolve caller id issues. We were experiencing a similar issue with certain Sprint mobile phones and this patch resolved that IVR issue. However, we do not have access to cell phones from the carrier you were having IVR issues with to confirm this fix. Please let us know if this patch resolves the IVR issue.

Keep in mind that we can not guarantee caller ID, if a carrier is not sending the information correctly it is possible that our carriers may not be able to forward that caller ID information to our IVR systems. This is not something that is completely in our control.

Regards,
Plum Support

Posted: Mon Mar 19, 2007 8:43 am
by melsullivan
Thank you! We will test it out and let you know.

Thanks,

Melanie Sullivan

Posted: Thu Mar 22, 2007 9:46 am
by melsullivan
Hello,

We tested this with the following cell phone providers:

Bell
Rogers
Telus

All the caller IDs came through fine on the local (617) number but did not come through on the toll free number.

In addition we have another client reporting the issue with an Aliant cell phone. We have not been able to test with her yet if it works on the local number but not the toll free.

I have all the activity/session logs relevant to the testing we did today, please tell me who I can email them to for further consideration.

Thanks,

Melanie Sullivan

IVR platform cannot guarentee caller id

Posted: Fri Mar 23, 2007 12:25 pm
by support
Hello,

We will discuss our options with our carrier. Unfortunately there does not appear to be anything more that we can do in our IVR systems. If there is anything that can be done with our carrier we will do it to resolve the IVR issue. However, as stated previously we are not in control of the information provided to us and we can not guarantee caller id. If any new information is gained we will pass it along.

Regards,
Plum Support

Posted: Wed Mar 28, 2007 4:41 pm
by melsullivan
The question I still have s this - why can we see the correct ANI numbers coming in on the 3663 line but only not on the toll free ones? What is the difference in these?

Thanks,

Melanie Sullivan

IVR issue with caller id is still being looked into

Posted: Wed Mar 28, 2007 5:15 pm
by support
IVR calls to the 800 numbers are transported over a different carrier than IVR calls to the Boston local lines. There appears to be a difference in how the lines were engineered by our various carriers. We are still looking into the IVR issue with them.

Re:

Posted: Wed Jun 13, 2012 4:05 pm
by steveosiris
melsullivan wrote:The question I still have s this - why can we see the correct ANI numbers coming in on the 3663 line but only not on the toll free ones? What is the difference in these?

Thanks,

Melanie Sullivan
Working on a similar project, and I would like to know what the difference between these two lines is? Did you ever figure out the workaround for this? I am curious if it would make it easier for me if I switch to . I have heard that switching to may solve this issue. Sometimes, these issues can be solved just by adding along with , especially if you are in a big office. Any info would be great. Thanks.
-Steve

Re: Cell Phone session.telephone.ani not coming in

Posted: Thu Jun 14, 2012 8:38 am
by support
Hi Steve,

There is still nothing we can do to obtain the "correct" ANI, as this data is given to us by our carrier. It's up to the carrier to pass us this information or not.

Regards,
Plum Support