timing opx-ringwait

Can anyone explain exactly what this parameter does? The documentation suggests that it has to do with the time between rings on an FXO port configured for plar opx connection, but as far as I can tell the FXO call detection does not work this way. It appears that IOS sets a single call timer when an FXO port starts ringing and after this time expires subsequent ringing is taken as a new call. Worse, caller ID information is forgotten at this point so the "new" call is anonymous.

I can't tell whether the time set by "timing opx-ringwait" is used for the call timeout, but it seems to affect it. Unfortunately it cannot be set to more than 10 seconds and I would like calls to be able to ring indefinitely (and certainly more than 10 seconds). Timeouts ringing infinity doesn't do it either.

Dan Lanciani ddl@danlan.*com

Reply to
Dan Lanciani
Loading thread data ...

This sounds like a bug and you should open a TAC case. I can certainly understand why this bug hasn't been found before. Having a call go unanswered after 10 seconds without sending it to VM or a call-queue is very unusual.

Reply to

call-queue is very unusual.

Not being a Cisco guy I can't respond to the OP directly but this comment strikes me as weird. There is nothing unusual at all in having a no-answer time anywhere between 15-30 seconds, even longer for hunt groups. Each ring takes 3.2 seconds, and most people actually want 4-5 rings before VM.

It sounds like the parameter the OP is asking about is a delay before the first ring (purely a speculation on my part) which may be useful if getting a caller ID from a loop start line. In which case it would be 2 seconds.

Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.