Implications of MICS firmware point releases?

[KrisBoutilier]

I'm trying to locate a possible issue with one way audio on PRI based calls that are being bridged through a MICS 4.1 based Norstar. Ie. a call is coming in on PRI-A for a local DN and then being call-forward no answer (or busy) back out of the same PRI-A to a remote number via a different B channel. Perhaps 'looped through' would be a better way of putting it.

I have two MICS 4.1 KSUs, both configured identically. On only one system there seem to be sporadic cases of calls being connected, but only one way audio (ie. from the destination party back to the source, but not the other way). This is particularly noticable when a problem call is terminated to a remote voicemail system, wherein a correct length but completly blank voicemail is recorded. By 'blank' I mean that if the resulting audio file is opened in an editor the signal level is all 0's - not even any background noise. I can find no specific pattern to the occurances of problem calls, other than that they only seem to occur on one of the two units.

Looking deeper into the KSUs themselves I notice that the suspect system has firmware '30NdG00 NAT' whereas the other has '30NdG15 NAT'. My spider sense tells me that the ...G15 refers to a point release of the firmware and that might have encompassed a patch to my issue.

Question: am I interpreting the different version numbers correctly? If so, is there any way to obtain a changelog between the two versions? If not, is there somewhere I can obtain/upgrade to the exact ...G15 version?

Note that I don't want to upgrade beyond MICS 4.1 itself at this time and I don't have a COAMS contract. A per-incident for-fee option would be considered.

Thanks for any input/suggestions.

Kris Boutilier

 

[bkrike]

I don’t know that you will be able to upgrade to G15. I would just a recommend an upgrade in general.

I can tell you that it is a known problem that I have had myself. Even posted it here back in ought-3

thread799-677743

 

[bkrike]

In my post that I referenced from 03 I said that changing the line to A&R fixed the problem. I don’t know if it actually fixed the forwarding problem, or just allowed me to do a line redirect. It seems strange that changing it to A&R would fix the forwarding communication problem. But it also seems strange that I would write that unless it were the case.

So, I cant remember for sure if it worked for forwarding, but you may want to just try the A&R thing to see if it makes a difference.

 

[KrisBoutilier]

That sounds like it might just be my problem.

Each phone has at least one target line set to Ring Only that's used to call in to that set from across a private network. In turn the set is configured to forward unanswered calls out to a remote Voicemail system. Calls originating locally to the problem KSU have not experienced any difficulties, however calls ringing in, being answered and then transfered within the same KSU to a set that is CFNA out to the remote voicemail system would fall foul of the bug you've pointed out.

What may have been confusing the issue for me and making it look intermittant is that incoming calls on the target lines are usually pulled back and rerouted directly to the voicemail system if the called party doesn't answer in a reasonable period of time, thereby avoiding looping through the KSU and burning up b-channels... which accounts for the lions share of the calls.

I will switch a few sets over to A&R and see if that changes things.

As another datapoint for those who may read this sometime in the future; there is another bug manifesting in ...G00 whereby the outbound target line group for some call routing groups randomly flips back to Pool-A from PRI-A after power-off reboots. Neither of these issues seem to be present in ...G15

...G00 dates from late 1999 and ...G15 from late 2000. Lots of time for things to have been improved upon. Oh what I would give for a changelog.
:-/