[OpenSIPS-Devel] Avoiding creating outgoing TCP connections for NOTIFY requests

[Saúl Ibarra Corretgé]

Hi Bogdan,

On Oct 12, 2012, at 5:15 PM, Bogdan-Andrei Iancu wrote:

> Hi Saúl,
> 
> On 10/12/2012 06:54 PM, Saúl Ibarra Corretgé wrote:
>> Hi Bogdan,
>> 
>> On Oct 12, 2012, at 4:35 PM, Bogdan-Andrei Iancu wrote:
>> 
>>> Hi Saúl,
>>> 
>>> Well, looking at this particular case (presence), we have 2 options:
>>>    1) simplify everything and gave internally the tcp_no_new_conn_bflag set when firing a NOTIFY.
>> Not sure if I get this one. How/where would that flag be stored? You mean if the flag was set when handle_subscribe was called, for example?
> well, the flag is internally translated to a static variable, so the presence simply has to set a variable :)
> See "tcp_no_new_conn" .
> 
> 
>>>    2) remember (in the watcher structure) if the subscription was from behind a NAT and if so, internally set the tcp_no_new_conn_bflag set when firing a NOTIFY for that subscription.
>>> 
>> This is more or less what I had in mind, so I'm all for it.
> Yes, correct.
> 
> 
>>> Ideally, in both cases, if tcp_send() fails, we should terminate the subscription, IMHO.
>>> 
>> Right now IIRC OpenSIPS will only terminate the subscription if a 408 or 481 is received for a NOTIFY. Yes, we should terminate it if tcp_send fails. (More on this a bit below).
>> 
>>> Now, in long term, I was brainstorming with Vlad to try to get rid of this blocking TCP stuff (generally in openspis). The idea we came up with is (if the write/connect will block) to move the operation in the TCP main process in the epoll (to wait to write indication) - that will mean to move the buffer in shm, and to attach it to the TCP conn for waiting; of course, the TCP conn states will have to be re-worked to make place for the waiting states.
>> Makes sense :-) This way the worker process would be freed quicker even if TCP will later fail.
> Exactly - as you said below, it will be more like UDP .
> 
> 
>>> This is no an async operation, we simply move it in a different process for waiting - in such a case, we will not be able to tell if the op was successful or not - the process which wants to do the TCP write will simply continue with success even if the actual write is still ongoing in a different process. There is work around for this as we cannot suspend the execution of SIP msg in opensips (there are no context) - this something that only 2.0 can do.
>> If I understood correctly, since we lose the state, TCP would behave a bit like UDP, in that you don't know if something went wrong, until the transaction timeout kicks in and a local 408 is generated. Is my understanding correct?
> Yes, it is.
> 
> An idea we are investigating is to be able to push back (from transport layer) the failure event to the SIP signaling level - so if the tcp_send failed from stateful request, to dig in for the transaction and to send an negative reply back.....maybe this will be in phase 2 :). But in the worst case, a failure of sending will translate in a timeout at SIP level.

I think it's a fair tradeoff for a first iteration. If it can be improved later then it's even better :-)

> 
>> If it is, a huge +1 from me. Yes, it's a workaround, but it's the best thing we can do with the current design, and we really need TCP working properly soon.
>> 
>> iOS devices, for example, can't send an application to background and be woken up using UDP, they must use TCP or do manual polling, which kills the battery.
>> 
>> This is also really important for presence, in Blink we can't use UDP for subscriptions to presence because packets are so big they fragment and things just break. As for what you said about terminating subscriptions, if TCP now would behave more like UDP, if a NOTIFY can't be sent out then a local 408 would be generated, which (with the current code) would terminate the subscription, so looks like we may not even need to do anything there :-)
> Well, that was our idea...to come up with something generic that will transparently fix most of the cases, without hacking tens of places :D
>>> What do you thing of the above idea ? :)
>>> 
>> Love it :-) We already switched to TCP for the above stated reasons, so if you need testing let me know, I'll be more than happy to do so.
> OK, this will take a bit of time to put in place...I will keep you posted with the progress.
> 

I'm glad to see we are on the same wavelength :-) Have a nice weekend!


Regards,

--
Saúl Ibarra Corretgé
AG Projects