PLM input: Don't make it configurable - this adds something more to do/screw up and value isn't apparent. Eg. Why make it 20, 60 or 9999?
9999 is the same as no timer; seems to make sense. The main requirement is that if the first gateway is blocked or not able to handle traffic then calls are made to the secondary gateway. Would another consideration be to ensure the first attempt is nolonger active prior to the second attempt (on backup gateway) being tried. -----Original Message----- From: Campbell, Alfred (BL60:9D30) Sent: Tuesday, February 24, 2009 4:58 PM To: [email protected] Subject: Re: [sipX-dev] XECS-839: Gateway redundancy Martin, I think if we make the default high enough and not configurable it handles your concern. What if we make the default 9999. Al -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steinmann, Martin (BL60:2500) Sent: Tuesday, February 24, 2009 3:36 PM To: Worley, Dale (BL60:9D30); Beeton, Carolyn (CAR:9D60) Cc: [email protected] Subject: Re: [sipX-dev] XECS-839: Gateway redundancy >> >> A simple way of improving things is to specify a longer timer for >> gateways. This can be done by putting an Expires tag in the >> fallbackrules.xml file. Changing it to 60 seconds gives a much better >> user experience. > >And we could make the timeout a configurable feature of a gateway object >in sipXconfig. And what criteria would the admin use to figure out what the right time-out value is? I think Alex stated the problem quite correctly in his original statement. How can we get to deterministic behavior when it comes to gateway redundancy? --martin > >This seems like a very good idea, since it's simple and substantially >improves the user experience. It's not a complete solution, but it >makes life much better and can be done quickly. > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
