The answer is in the 2 issues and Dale's answer: I don't recall where the timeout is set, but it is a variable parameter in the SIP stack and can be adjusted straightforwardly.
XX-6065:sipX seems to be configured with T1 timer set to 100msec instead of the recommended default of 500msec. Increase T1 to 500msec and you're good. I really don't see why T1=100msec is used to be honest, very aggressive. For example: my outgoing traffic goes through an ACME Packet who dampens this back to RFC timers. XX-7037:The constraints are that the value should be high enough to avoid incorrectly marking destinations as unresponsive, but low enough to not annoy users in HA systems with nonresponding components. Here maybe a nice fix could be made. Lets see if I understand this correctly: HA means that SipX got more then 1 server for an SRV query. It starts with one of the servers, A. Sends an INVITE, if it doesn't get some answer within T-HA seconds then it could -in parallel- send the INVITE to another server B, and so on. If A never replied after doing the RFC cycle (7 INVITE's) it can be marked as unresponsive, same for B etc. Probably the client hangs up before a full cycle is completed, so maybe their should be a T-UR (unresponsive) as well, about 4 seconds should be fine. But now we are rewriting RFC's... Paul Ari Sonesh <ason...@gmail.com> wrote on 11-11-2011 00:18:30: > There are 2 open related incidents on this issue: > > http://track.sipfoundry.org/browse/XX-7037 > > http://track.sipfoundry.org/browse/XX-6065 > > Does anybody have recommendation how to get a quick fix? > > Thank you all. > > Ari > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
