strange one i encountered this month. we have done a UC500 48 user with a 8 port FXO setup. we have 4 lines connected to a GSM gateway and 1 to a Land line.
ive received two calls in the past two weeks from the customer stating that they cannot make outgoing or receive incoming calls (The GSM is thier primary incoming/Outgoing).
i checked today and sure enough i ring in the PSTN number, it goes of hook and then silence. They cannot make any outgoing calls either.(they get unknown number and then busy)
Note: i can dial into the LAND line number and everything is fine.
Now ive checked parameters, timeouts etc. when the issue is occuring i even disconnected the GSM gateway and plugged in an analog phone directly and it works. ive disabled caller id and shut no shut the ports as well.
i have also shut no shut all ports and nothing fixes it. the only FIX is a reboot of the entire system. im sure its going to fail in the next couple of days again.
i did a vpm signal debug and what its telling me is that it cannot connect the fxo port to the DSP channel.
my first step is to upgrade the IOS which im actually about to do but i was wondering if anyone had similar issues?
any assistance would as always be greatly appreciated.
well i upgraded the IOS and after a week we got the call that the system isnt receving or accepting calls again. A reboot as usual fixed the issue. i could'nt run any debugs at the time as the customer was understandably pissed and need to make a call ASAP.
im stumped with this one as it has to be a bug but im not seeing any mention.
this is what i have observed.
1. calls simply stop working
2. i call in the number and the FXO does NOT go off-hook or detect a ring
3. i shut down the port and re-enable and it detects but after the second ring it goes to the auto attendant but you do NOT hear any voice.
4. during this time if i change the PLAR to a user phone and call in, it rings twice, then it lookg like it is connected but nothing happens on the phone.
5. it then disconnects itself afterward.
6. the debug from the last time indicated some issue binding the port to the DSP.
any assistance would really be appreciated.
PS. We have two other implementations - 24 user and a 32 user with the same setup and IOS etc that works fine.
im thinking of swapping PVDM modules?
both other installs have the same setup.
IOS version uc500-advipservicesk9-mz.124-22.YB4
PVDM version was 1.1.3 (something along those lines)
and after upgrade is 24.1.X (Something along those lines)
im currently awaiting a remote vpn connection to verify all the exact configurations.
ill post as soon as i get it.
Always the first thing i do in situations like this :). ill defintely keep the post up to date with developments.
this document actually describes the issue but the cards are not applicable. everytime it happens i see one of the FXO ports being off hook. hummmmm.....
Just posting an update. We replaced the PVDM module itself and for now its holding. ill know for sure in two weeks. of course if i dont post again it means that the problem is solved :)
thanks once again.
well what we did for now was "scrap" our lab UC500 to get to the PVDM. im still waiting to ensure that the replacement actually works. im working with TAC and they asked if i had any spare as well.
difference though is that the original was a 2-64 and we replaced with a 32 but that shouldnt really matter anyhow as its only using 8FXO ports
that didnt fix the issue :(.
im thinking board now as i really cant see how software is affecting this.
IOS was upgraded, Cards reseated, PVDM replaced with known working.
We have the built in FXO as well as a VIC2-4FXO we placed. we had all the lines on the VIC2-4FXO and i just asked the customer to change it to the built in FXO but same result. whats interesting is i asked him if he is seeing any lights on the FXO and he is seeing green lights on the orginal FXO we had the PSTN lines on. meaning, the FXO is looking as though it has active calls but really does not.
again, i cant shut and no shut as it does not work. the only fix here is a physical reboot of the router.
P.S i have calls going to the AA. im wondering if by some weird change this CUE may have something to do with this.
Well issue is still occuring and its getting a little ridiculous now. we have upgraded, downgraded pvdm replaced still no dice.
im awaiting TAC to replace the entire system.
What "red flags" me is that it happens every four days. hardware issues cant be that exact. im checking through my AA script to see if i missed anything.
i understand that the Internet gives issues (lack of connection) as well.
im collecting a tech-support to see if there is any load on the cpu causing the system to behave like this.
Did you ever find a solution here.
We are having the exact same issue. TAC have replaced the hardware once and still same problem.
Hoping there is a workaround somewhere.
Ill try to remember as much as possible here as i remember this was a very troubling issue.
So the equipment was replaced and we had the same issue. we did a factory reset, restored the backup etc and after some time the same issue occured.
We ended up placing a CME system temporarily and took the UC 500 and placed it in our environment. Everything worked fine with both the CME system at the customer site and the UC 500 in our office
The difference it seemed for us was the GSM gateways. We came to the conclusion that the GSM gateways was probably sending a signal (we totally were shooting in the dark here) and that was causing the issue. The reason here is that we made no changes but at our office we were using LAND lines.
In any event, the customer still to this date has the replaced system back with them and we have not had any complaints.
Im trying to remember what we did so bear with me....
my engineers were not able to fix after the replaced system was put in and i recall we also replaced the GSM gateways and still had the issue. I logged in and did the following:
1. Removed all the pre-configured Hunt groups and dial-peers that the system came with.
2. I also shut down all un-used ports (including any FXS)
3. i manually recreated dial-peers and hunts and used only the active FXO ports to be members
4. Placed a timing supervisory disconnect to 300 on each active voice port
when i reach in office ill speak to my engineer and see if we can get a final running config.
BTW, the originially replaced uc 500 (Another was bought since it wasnt under smartnet) is still at our offices and gives absolutely no problems whatsoever.
Id say in summary, if the issue is the same as ours, you may want to look at the FXO to PSTN tie in and im 100% sure this is what we adjusted. It also didnt appear when we tested in our office so we had to be onsite to observe and fix.
hope this helps somewhat and ill try my best to see if we got a final working config for you.
wow thanks for the reply, I wasn't sure if I would see anything here.
We have replaced the UC540, our situtation is a little different thought. We have an extra VIC2 card with 4 additional FXO port being used for incoming PSTN lines from an internal hospital PBX.
I have read about the timing supervisory disconnect and we will give that a shot too.
I have a feeling some type of singaling makes the FXO ports freeze up. A restart is the onlything that works.
I am working with level 2 TAC now and will try the above mentioned. Much appreciated.
shoot us a post if you did get it resolved. This one stumped us for a while and the customer was about the throw the box away
good luck and ill respond once i can