We have a Hotel deployment with Adtran's 924 where they like to do Voice mail blast to guest. This means that there's MWI to all 24 ports and there's cases that ports of dropping. I've been asked to bounce the ports which have brought them back up. Can you tell me if this is unusuall and if so is there anything we can do in the config to avert this from happening. Below is an example of the interface config and user.
!
interface fxs 0/2
mwi neon cadence 1000ms voltage low
no shutdown
!
!
voice user 7307
connect fxs 0/2
last-name "7307"
password encrypted "353137ad1740f72c81782ec3266d6bc6f99f"
sip-identity 7307 T01 register auth-name "7307" password encrypted "1f161f322d
54fdb295d50b68f6e7eec6ada1"
sip-authentication password encrypted "353137ad1740f72c81782ec3266d6bc6f99f"
!
Thanks,
Omar
Omar,
I just wanted to post the results of this fix on the forum in case others experience this issue. Below are the release notes describing the issue.
If the MWI lamp is lit on a user configured for NEON MWI, the FXS port tied to that user will lockup if the FXS user goes on hook while in the battery disconnect state (due to the far end hanging up first).
The fix was made available in R10.3.1 firmware and should be included in all R10 versions higher than this.
Thanks!
David
Hello Omar,
Thank you for posting to our forum! The config you have posted looks fine. Can you elaborate on what happens when the ports drop? Do the lines become un-registered or do the physical FXS ports go down? How do you bring them back up? The answer to these questions will help us determine a course of action. The next time the problem occurs these commands would be helpful:
show interface
show sip trunk
Also, what version of firmware do you have on the Total Access 924?
Best Regards,
Geoff
Geoff,
Thanks for getting back to me. What usually happens is that the FXS port drops. The sip registration stays up that's not the problem. The last few times the fxs does come up on it's own if not I do a shut and no shut to bounce the fxs port. Below is the last event log with such an event but this one came up by itself and version.
2012.05.26 16:28:28 FXS.0/3 Fault Condition: Possible cabling issue - Port disabled for 30 seconds
2012.05.26 16:28:28 INTERFACE_STATUS.fxs 0/3 changed state to down
2012.05.26 16:28:57 FXS.0/3 Fault Condition Cleared: Port available
2012.05.26 16:28:58 INTERFACE_STATUS.fxs 0/3 changed state to up
ADTRAN, Inc. OS version A5.02.00.E
So you don't think that doing a VM blast should be a problem?
Omar
No problem Omar. Thanks for sending in that information. The fault condition is usually the result of a short on the 66-block or an analog wiring problem on the Customer Prem. When the fault is reported, the FXS port shuts down for 30 seconds. Does that message ever occur without the VM blast? I would like to verify that the problem you are seeing is not a result of a physical wiring condition.
Thanks,
Geoff
Geoff,
In several cases I've seen that concurrent fxs do go down which does indicate a short. At the moment though we are noticing the dial tone is gone but if one calls the line it rings. I'm working with another B2B provider and suspect there's something going on there and the common issue is that there stutter tone when the dial tone is lost.
I believe that the B2B provider has a ticket open with you all as well.
Omar
Geoff,
Just touched base with our B2B UA partner who apparently has reached out to Rob Padgett in Adtran. Is it possible for you to link me to him. I've made an added change to the config which is basically replacing the defaulted "message-waiting both" on the voice users to "message-waiting lamp only". We've not had a change to troubleshoot and see if this makes a difference. I will let you know.
Please let me know if you can link Rob onto this?
Omar
Omar,
I just wanted to post the results of this fix on the forum in case others experience this issue. Below are the release notes describing the issue.
If the MWI lamp is lit on a user configured for NEON MWI, the FXS port tied to that user will lockup if the FXS user goes on hook while in the battery disconnect state (due to the far end hanging up first).
The fix was made available in R10.3.1 firmware and should be included in all R10 versions higher than this.
Thanks!
David