Jump to content
Vodia PBX forum
netpro78

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.

Share this post


Link to post
Share on other sites

Hi,

Please enter the regular expression: 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  in the regular ANI section of the trunk you sent below as shown in the image.

1.png

Share this post


Link to post
Share on other sites

For some reason it did not work when I copy pasted everything above, however:

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

Worked just fine

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Hi,

 

We dug up one of the strings that worked for us previously:

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

Please try it out.

Edited by Support

Share this post


Link to post
Share on other sites
Hi,
 
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.)
 
Cheers,

Share this post


Link to post
Share on other sites

Yes this should be working. Please make sure that you use the {from} pattern in the SIP header (or {ani-raw}), e.g. From-header or PAI-header.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×