Another day, another bug...

[NuggiFirst]

Beware of this bug:

Two (or more) IPO's in Small Community Network. CO-lines on central system. In "Incomming Call Route" on the central IPO, some of the DDI's are pointed to Extn's on other IPO's.

If one of the other IPO's are rebooted, the programming in "Incomming Call Route" on the central IPO wi'll disappear! The entry wi'll still be there, but the destination-field is blank!

Isn't there any kind of in-house testing before GA?
It's kinda hard to explain customers about problems of this kind...

Problem seen on 2.1 (24) and (27).

 

[xlr8neo]

I would have to say that this is not possible one unit to change the config of another. I know there have been some problems with software but this one is out of the x files.
I would be surprised if this was an actual fault but hey thats life!

 

[intrigrant]

I'm investigating a similar problem on 2.1(24) in a SCN of five IPO's.

 

[NuggiFirst]

I bet you it's possible!!

I have three systems with this problem.. I have to check on them on a very regular basis..

There's A LOT of support work in an v2.1 IPO

 

[intrigrant]

Do you enter the stationnumber in the incoming call route?
If yes, then create shortcodes for them and point incoming call route to the shortcodes, that should not dissapear after a reboot!

 

[crashtest1000]

Make sure all your names and perhap your groupp names numbers are not duplicated on the SCN this will cause that sort of problem.

 

[YeOldPhoneGuy]

I was told this was a "feature" in Release 2. The train of thought was something like this:

If the SCN network looses connectivity, buttons programmed on phones pointing to users on other IPO's will not be reachable. Soooooo to HELP the users I will remove the programming, thus preventing them from attempting to reach user that would not be avaliable.

I beleieve they felt it would also be "enhanced" in future versions so as to not deleted the entries automatically.

Also don't forget that in mulisite installations, I have run into this several times, multiple people may have manager and configs open for the same IPO. Last one to close manager wins!!!!

Cheers

Me

 

[kristiandg]

Hey xlr8neo,

When I first set up 2 systems (403's) in a lab, when they would register with each other via SCN, they would trade DB's. All the sudden the phones would trade users/extension numbers. Had to wipe config and rebuild from scratch.

It is possible...

Kris

 

[IPGuru]

Who told you this was a feature YeOldePhoneGuy?

& I hope your reponse was what we are all thinking "BullS**t"

Enhanced = fixed

 

[YeOldPhoneGuy]

IPGuru

Yes I did make a comment similar to what you mentioned. The issue may have been specific to the version software the customer was running. Sorry I don't remember the exact version. I will look it up the old config's tomorrow and let you know.

The engineer did state, to my suprise, that the developers indicated that the behavior was "intentional".

I recall there was a timer involved, allowing for the link to bounce for a short time, but when the timer expired it "adjusted" the programming to the buttons.


Cheers
Me

 

[YeOldPhoneGuy]

IPGuru

Sorry I forgot to mention, the engineer also mentioned that after discussion with developemnt, they felt the reason for the feature behaving as it did was sound. They "might" look at alternative methods to accomodate SCN failures in future software versions.

I am curious and request feed back from this forum. I respect the information provided here. I will get the version software thet customer was running and provide it.

If this was indeed intentionl behavior you should all be experiencing it. Are you? Look forward to your feedback.

Cheers
Me

 

[NuggiFirst]

I got some respons from our suppliers support. They could recreate the problem, even in a faultless testsetup (no "illegal" thing in the cfg's). Is they used names instead of extension in "Incomming call route" they couldn't recreate the fault. Haven't tested this myself, but it looks like a solution.

At my customersites, i use a phantom user, with divert all, to send the DDI to other sites. I haven't seen any faults since.

 

[Raffles666]

The answer is, as has already been stated! To get a DDI on one site to go straight over the VoIP link to the other site(s) without disappearing is quite simple (and it did it in all 2.1's as well).

Eg.
Incoming call route - Incoming Number (DDI) '123456' - Destination '8201'
Shortcode '8201' - Telephone Number '201' - Line Group ID '50' (this is the line group of the VoIP link) - Feature 'Dial'

Be careful if the incoming site has LCR on as an entry like the following will need putting in there as well (or the LCR leading digits will probably get added to the call). Shortcode '201' (not 8201!) - Telephone Number '.' - Line Group ID '50' - Feature 'Dial'


This will route DDI '123456' to extn '201' on the system on the end of VoIP line '50'.

This will not get deleted/erased when you reboot any of the systems.

Hope this helps




Old school Alchemy engineer - trying to keep up with the times