[OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

[Bogdan-Andrei Iancu]

Hi Dan,

I agree it is not a easy thing to do, neither bullet proofed, but the 
big question is : does it do more good than harm ? also, what are the 
other options we have here ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/05/2012 05:57 PM, Dan Pascu wrote:
> 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
>
>
>
>