ANI problem after upgrade to 61.1

[netpro78]

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.

[Support]

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.

[Vodia PBX]

The new ANI is much more flexible than the old, hard-coded way: https://doc.vodia.com/trunk_ani

[netpro78]

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

[cwernstedt]

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?

[Support]

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 December 10, 2018 by Support

[cwernstedt]

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,

[Vodia PBX]

So far https://doc.vodia.com/trunk_ani has proven to be very flexible to deal with all sorts of situations. The pattern above contains the from-cell:ext-ani twice that can't be the answer. 

[cwernstedt]

Why isn't the below working?

from-trunk:from trunk-ani 

(If coming from trunk, use from; otherwise use trunk-ani if configured.)

 

[Vodia PBX]

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.