Inconsistent Call Type behavior

[networthfs]

I was doing some experimentation with call forwarding and came across some inconsistent behavior that may indicate a firmware problem or more likely a problem with my knowledge level.

Scenario:
Quadro4x, Firmware 5.0.11
Testing ZeroOut and Unconditional Forwarding(UCF).
Calls initiated in two ways:
- From an internal extension dialing the extension being tested
- From an external PSTN into FXO with “Route incoming FXO call to Extension” 00. Caller then enters two digit extension being tested.

First experiment:
Call Type set to PSTN for both ZeroOut and UCF.
RedirectAddress/ForwardTo is areaCode+number (without the plus signs).
In all tests both ZeroOut and UCF work as expected, i.e. the call is successful routed out a FXO-PSTN line.

Next experiment:
Call Type set to Auto for both ZeroOut and UCF.
RedirectAddress/ForwardTo is 9+areaCode+number (without the plus signs).

If a call is initiated from an internal extension to the extension being tested, both ZeroOut and UCF work as expected.

If a call is initiated from an external PSTN line both ZeroOut and UCF fail, with different Epygi messages.
ZeroOut: Number does not exist.
UCF: Number temporarily unavailable.

My first question is whether the different Epygi messages are significant or simply inconsistent software?

The second question is the obvious question. Why did ZeroOut and UCF fail when the call is initiated from an external PSTN?

[davrays]

Theoretically you should get "Number does not exist" in both cases (UCF and ZeroOut), and on my Quadro it does work like that. Probably there is something more in the config, which causes Quadro to look for more destinations and so give "Number temporarily unavailable". If you paste here the Call Controling logs with "developer loggiong" enabled, I may be able to tell the reason.

The second question - "Auto" option works via routing table. As your "9*" rule has PBX folter enabled, it is filtered out when you call from PSTN (Local callers are allowed to use the rule, while the PSTN callers are not).
With the "PSTN" option you call directly, bypassing routing table, and so are able to reach FXO line regardless of the caller.

Best regards,
David

[networthfs]

two text files attached with logs.


You said: 9* rule PBX filter enabled....
I assume that I can't modify this because when I goto Call Routing there's no check box next to any of the 9 related entries?

You said: Auto option via routing...
Clearly the documents state that too.

Is there a place in the docs that describes who/what goes thru the routing tables and what doesn't? Or is it simply that internal callers (PBX) can access the routing table, and external callers (PSTN,SIP) can't?

[davrays]

Thanks for the attachments. I retested the same on my Quadro, and this time got the same results as you. Not sure how I tested before

Yes, you get different voice messages in case of UCF and ZeroOut, though in both cases the reason is the same: the destination number cannot be found in the Call Routing Table, when the original caller is not local (because the rules are filtered out). There is some logic behind that inconsistency: in case of UCF the message refers to the originally called number, which may become available after user returns to the office and dial "*4". While in case of the ZeroOut, the voice message refers to the new number, which user requested by dialing "0".
Whether that logic is right or not, this is the way the device is working, and I don't think it is bad way.

You said: 9* rule PBX filter enabled....
I assume that I can't modify this because when I goto Call Routing there's no check box next to any of the 9 related entries?

You can add another rule, which is pretty much the same, but doesn't have "PBX" filter. But please take into account that if you do that, you make that rule public, and any SIP caller can use that, if he dial with corresponding pattern. So you have to secure your device, if you remove PBX filter from PSTN or ITSP rule.

Is there a place in the docs that describes who/what goes thru the routing tables and what doesn't? Or is it simply that internal callers (PBX) can access the routing table, and external callers (PSTN,SIP) can't?

I personally don't know such place.. But I don't read those docs too much.. , so maybe they have such description, and I just don't know the place.

It is not that simple. In short I would describe it the following way:
Everything, which is dialed into the device, passes through CRT (call routing table), whether it is a local call from FXS or IP phone, or a call coming from SIP.
In more details:
- CRT is used by local callers, when they dial something from the phone (if that is not service code (starting with '*') or speeddial pattern (starting with '#').
- CRT is used,when any kind redirection (UCF, BCF, NACF, zeroout, queue redirection etc etc) is configured in the WebGUI as an "Auto" option
- CRT is used by SIP callers, if the call doesn't match to any of the existing usernames on the extensions of the device. If the "Route All SIP calls to Call Routing" checkbox is set, even that calls go to the CRT.
- CRT is used by the PSTN callers, if the FXO or ISDN calls are routed to "Routing"
- CRT is used, when somebody connects to AA with default scenario, with "Send AA Digits to Routing Table" chackbox enabled.
- CRT is used, when somebody connects to AA with default scenario,
then use "Call Relay" (login as extension and dial).
- CRT is used, when "dial" object is used in the custom AA VXML script.

Thats it basically And this covers almost all ways to call via Quadro
If somebody remembers more ways to use CRT, I can update the list here