2018 3.2.2 firmware breaks on InboundCallRoute delay syntax, crashing Obi

[AntonioH]

ModelName   OBi202
HardwareVersion   1.4      
SoftwareVersion   3.2.2 (Build: 5859EX)

DELAY SYNTAX FOR INBOUND CALL ROUTE
https://www.obitalk.com/forum/index.php?topic=1958.0
https://www.obitalk.com/forum/index.php?topic=4838.0

Please see the above forum pages for grammar for delay in an InboundCallRoute.

You find this setting in Voice Services -> SPx Service -> X_InboundCallRoute parameter.

New firmware pushed down to Obi devices this year is incompatible with existing syntax of InboundCallRoute.

Specifically, if any Obi has an inbound call route featuring a rule with a delay, then a call to the service provider with that route will result in the Obi crashing and rebooting.

Here is an example of an InboundCallRoute that has been executing correctly for years:

    {{ph1,sp3(XXXXXXXXXXX),sp2(YYYYYYYYYYY;d=15)}

This rule rings Phone 1 while initiating forwarding through SP3 and, for failover, fifteen seconds later through SP2. 

This rule worked fine until this year's pushed firmware updates.  The new firmware has a bug making it break InboundCallRoute backwards compatibility.  The new firmware can not handle the InboundCallRoute, causing the Obi device to crash and re-boot upon any phone call received by the service provider with this InboundCallRoute.  You know the Obi box is crashing as (1) ongoing calls on other SPs are dropped and (2) the System Status page stops responding but once back up again says the device has an UpTime of 0 Days 0:00:00.

Ripping out the delay parameter (";d=num") destroys the fail-over, makes the dual forwarding non-deterministic, but proves that the 3.2.2 firmware is failing on this syntax.

Obi Firmware team, could you please release a Hot Fix firmware update that correctly implements the InboundCallRoute's well-established delay parameter rather than crashing the device?

Has anyone else utilizing a delay in X_InboundCallRoute experienced failure after a pushed 2018 firmware update to your device?

Until the fix, I have had to rip out the failover SP2 rule and am praying SP3 does not ever fail me in the meantime.

Thank you for your consideration.     

[RFC3261]

Obi Firmware team ...

AFAIK, no one from OBi formally participates here in the *Community* forum (they may, or may not, read any particular post, but have not posted officially for quite some time).

If you have a support contract on your OBi, open a ticket: http://www.obihai.com/supportTicketForm2.php

[AntonioH]

Thanks, RFC3261, I have created a ticket.

Still, I am interested to know of any Obi users who have done multi-branch routing via InboundCallRoute, particularly with the goal of a fallback route engaged on a delay.  I know this feature used to work for me, so am eager to know if anyone has seen it stop working under the current firmware.

Cheers!

[Taoman]

I know this feature used to work for me, so am eager to know if anyone has seen it stop working under the current firmware.

I tested it and confirmed your experience. It's definitely a firmware bug.

I've never seen a situation where an inbound call will crash and reboot an OBi ATA before but that's what happens.

[RFC3261]

I've never seen a situation where an inbound call will crash and reboot an OBi ATA before but that's what happens.

In the real world, bugs happen.  Do you happen to know if the OBi stores sufficient log information (and then possibly sends the crash info upstream) when a crash such as this happens?(*)

(*) FFDC requires at the very minimum capturing the crash info (even if no auto-upload without confirmation), since reproducing failures is often difficult (although, apparently in this case, easy).