Folks,
Whenever a remote worker registers with wipXecs, the sipXproxy process
will start maintaining the pinhole to the remote worker by sending an
OPTIONS message every 20 seconds.  This process ensures that the
firewall & NAT in front of the remote worker will accept and forward
incoming requests from sipXecs.  Without that process, the firewall
would close the pinhole some time after the phone's last transmission. 

Recently, we have experienced some problems in the lab whereby
restarting the sipXproxy process can interrupt the generation of
pinhole-maintaining OPTIONS messages for up to 3 minutes.  This
interruption is enough for many firewalls to close their pinholes
rendering the phones behind them unreachable from the POV of sipXecs.
This situation heals itself the next time the remote phone refreshes its
registration but because sipXecs's max expiry value is one hour, a
remote phone can lose its ability to receive incoming for a full hour
following a sipXproxy restart.

To solve this situation, I can see two approaches which are not mutually
exclusive:

1- for remote phones that support a SIP keepalive feature, that feature
should be turned on;
2- sipXecs should significantly reduce the maximum registration expiry
for remote phones to something like 5 minutes.  

The latter would increase the work load of sipXecs but would ensure that
every phone returns to a fully functional state within 5 minutes of a
system reboot, sipXproxy reboot or network outage.  I'm not too
concerned about the increased work load - here is why.  Earlier this
year I was doing performance measurements on sipXecs and as part of my
test setup, I had to register 5400 users very often.  I had a SIPP
script that was doing the bulk registration at a rate of 100reg/sec and
the system could very easily cope with such a load...  

I would like to hear your comments on this.

Thanks you,
bob
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to