Jump to content

ANI problem after upgrade to 61.1


Recommended Posts

Prior to upgrading to 61.1 when a call was forwarded, or a cell phone was included on the incoming call, the recipient would receive the ANI of the original caller.  After the upgrade the ANI that is being received is from the extension that is doing the forwarding.  I have tried all sorts of custom trunk headers, and in the past using "Based on Incoming Call" worked properly, now I cannot seem to find a combination to replicate this lost feature.

Link to comment
Share on other sites

  • 2 months later...

When upgrading from 60 to 62.0, ANI behavior stopped being good, I'm not sure how to make it work.

Desired behavior (worked with version 60):

1) If the call originates from trunk, then the original caller ANI should be used when calling out to an extension's cell phone  .

2) if the call originates from internal extension then the extension's (if available) or the trunk's ANI should be used instead.


I'm trying to make it work with v62, but whereas the ANIs of calls originating from a trunk are presented correctly, calls from internal extensions are presented incorrectly (the internal account number is presented instead of the extension's outbound number ANI or the trunk ANI  . (So all calls from say, internal extension 999 would be presented as 999 instead of say +46314343455.)

On the trunk I'm trying this setting which seems logical to me:

ani_regular: from-trunk:from trunk-ani

I needed to put in "from-trunk:from" to make criteria #1 above work, but this also results in the bad behavior for calls from internal extensions.

How can I replicate the behavior of v60 so that things work again?

Link to comment
Share on other sites

Your suggested string (the below) causes the ANI from externally originating calls to now show (instead some other ANI is shown, extension or trunk )
from-cell:ext-ani from-cell:ext-ani from-cell:dom-ani from-trunk:from acd-ani ext-ani trunk-prefix dom-ani trunk-ani
So from our point of view the same as having nothing in the Regular ANI rule field. 
This string, on the other hand, causes the same bad behavior as before (internal extension numbers are presented as ANI to the PSTN) :

from-trunk:from acd-ani ext-ani trunk-prefix dom-ani trunk-ani

Note that this is the same as your rule, but with the from-cell clauses removed.
Why from-cell clauses in the rule field changes behavior in this way at all is a mystery as none of the test calls originate from a user’s cell phone. They originate from either an internal extension or from some random external number.
It looks like something is seriously wrong with the code here with regard to the parsing of the ANI rule field. 
Note that what I’m trying to do worked perfectly before and this isn’t a weird scenario. (One would certainly want to pass on the original ANI if the trunk provider is OK with it.)
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...