On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote: > Hi Dan, > > Well, as Ovidiu said, it is prone. BUT, this is not something particular to > re-INVITE, but to whatever > in-dialog pinging you may have from a mid-proxy.
I never said otherwise. > On the other hand, as Ryan pointed out here, the need to check the dialog > health from proxy side, without relying on special end-UA features (like > SST), is really critical. While it may be useful (I would not call it exactly critical), this doesn't mean that the implementation should introduce new issues. I'm not arguing against the idea of having a keep-alive mechanism here, but against particular implementations that introduce new issues. > So, I see two approaches: > 1) either simply live with the fact that races may occure and calls may be > dropped during a re-INVITE, but at least is a clear drop /cut I'm not sure you can explain your customers that their calls are being dropped because you have a race condition in your implementation which you are willing to live with... > 2) theoretically we can try to address the race at dialog modules level : > (a) If you have ongoing in-dialog transaction, do not do your ping , This was never the issue. You can always avoid this. > (b) if you have an ongoing in-dialog ping and receive another in-dilog > request from end point, try to delay it until your pinging is done..... This should work, but I don't see it working without a proper async reactor model. How do you plan to delay it, without blocking the worker? On another note, I also believe that a re-INVITE based keep-alive is also problematic because it has to implement the whole stream selection mechanism in the clients in order to know what streams to propose in the re-INVITE. Even so, triggering a SDP renegotiation every now and then is not very nice, regardless of it changing nothing in the streams. -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
