[OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it?

Mon Nov 14 18:27:10 CET 2016

Sorry!, after I added the code, opensips does NOT tries to connect. That is
my wanted result

On Mon, Nov 14, 2016 at 2:10 PM, Federico Edorna <fedorna at anura.com.ar>
wrote:

> Right!  Actually I've added the code in relay_reply function, not in
> reply_route, but I guess it has the same effect...
>
> Thanks!
>
>
> On Mon, Nov 14, 2016 at 2:02 PM, Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> I got you now: so you are trying to set the tcp_no_new_conn_bflag in the
>> reply_route, but OpenSIPS still tries to connect to the client?
>> After you added the code in reply_received function, OpenSIPS still tries
>> to connect?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 11/14/2016 06:06 PM, Federico Edorna wrote:
>>
>> Hi Razvan, thanks for your response
>>
>> I agree that it is dangerous to try to open a new tcp connection, that's
>> why we want to set always the flag and never try to open a new tcp
>> connection to the UAC.
>>
>> What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't seem
>> to work for a reply, for example what I've described in my previous email.
>> When opensips receives a reply from the callee (and has to do the relay to
>> the caller) but the caller tcp connection has gone, opensips will try to
>> open a new connection, even with the flag set. It is not a common scenario,
>> but it happens sometimes, that the tcp connection is reseted before the
>> call is answered.
>>
>> Maybe I cannot explain the problem in my English :(, please let me know...
>>
>> Best Regards
>> Federico
>>
>>
>> On Mon, Nov 14, 2016 at 11:24 AM, Răzvan Crainea <razvan at opensips.org>
>> wrote:
>>
>>> Hi, Federico!
>>>
>>> Not sure I understand your problem. That flag indicates OpenSIPS to
>>> avoid opening a new connection if he doesn't have one available. Therefore,
>>> if the connection to the caller closes between INVITE and 200 OK, that flag
>>> prevents OpenSIPS from opening a new one.
>>> Why would you like to get rid of the TCP SYN message? That happens and
>>> the TCP layer, saying that the data arrived successfully. Why would you
>>> like to prevent that?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 11/14/2016 04:05 PM, Federico Edorna wrote:
>>>
>>> Hi Răzvan,
>>>
>>> related to this topic, it seems that tcp_no_new_conn_bflag is not
>>> working on "on_reply" routes
>>>
>>> I've tried changing modules/tm/t_reply.c (opensips 2.2), using something
>>> like this:
>>>
>>>
>>> if (tcp_no_new_conn_bflag)
>>>                 tcp_no_new_conn = 1;
>>>
>>>
>>> in "relay_reply" function and now opensips doesn't try to open a new tcp
>>> connection. Without this code I cannot manage to avoid the TCP SYN from
>>> opensips to client when receiving a reply and tcp connection is not
>>> available.
>>>
>>>
>>> Just to clarify, the scenario is something like this:
>>>
>>>
>>> A opensips B
>>>
>>> --- INVITE --->
>>>
>>> --- INVITE --->
>>> <--- 100 Trying ---
>>> <--- 100 Trying ---
>>>
>>> <--- 183 Session Progress---
>>>
>>>
>>> <--- 183 Session Progress---
>>>
>>>
>>> --- At this point I wait opensips to close tcp connection
>>> (tcp_connection_lifetime=10) and then "B" answers the call ----
>>>
>>>
>>> <--- 200 OK ---
>>>
>>>
>>> Thanks!
>>>
>>> Federico
>>>
>>> On Thu, Oct 27, 2016 at 4:58 AM, Răzvan Crainea <razvan at opensips.org>
>>> wrote:
>>>
>>>> Hi, Rodrigo!
>>>>
>>>> Having OpenSIPS opening TCP connections towards client is a bit
>>>> dangerous, especially if the clients are behind NAT. That's because most
>>>> likely you will not be able to reach them, and opensips will get stuck
>>>> trying to connect (until it triggers a timeout). That's why the best way to
>>>> go is to try to keep the connection (ideally opened by the client at
>>>> REGISTER) as much as possible. This is usually done by pinging (as
>>>> discussed in a previous email). So my suggestion is to try to avoid opening
>>>> new TCP connections with clients, unless you really know they will always
>>>> be reachable.
>>>>
>>>> The behavior you are describing (INVITE vs BYE handling), might be
>>>> related to the fact that you are setting the tcp_no_new_conn_bflag[1] flag
>>>> for BYE messages, but not for INVITEs. Is this correct? If not, do you see
>>>> any errors in the script?
>>>>
>>>> [1] http://www.opensips.org/Documentation/Script-CoreParameters-
>>>> 2-2#toc101
>>>>
>>>> Răzvan Crainea
>>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>>
>>>> On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote:
>>>>
>>>> Hi.
>>>>
>>>>
>>>> After some log debug I have observed the following behavior in the
>>>> OpenSISP (2.2.1):
>>>>
>>>>
>>>> When OpenSIPS has to send a SIP INVITE to a peer through a TCP
>>>> connection that was closed before by some way, OpenSIPS open a new one and
>>>> then sends the SIP message to the peer successfully.
>>>>
>>>>
>>>> However, when OpenSIPS has to send a SIP BYE to a peer through a TCP
>>>> connection that was closed before, OpenSIPS open a new one, but doesn't
>>>> send the SIP BYE. In this case SIP BYE is discarded.
>>>>
>>>>
>>>> How to change the behavior of OpenSIPS to make it to send the SIP BYE
>>>> is such case?
>>>>
>>>>
>>>> I'm looking for ways of fix or workaround of a TCP tear down connection
>>>> that happens during dialogs.
>>>>
>>>>
>>>> Any hint will be very helpful!
>>>>
>>>>
>>>> RODRIGO PIMENTA CARVALHO
>>>> Inatel Competence Center
>>>> Software
>>>> Ph: +55 35 3471 9200 RAMAL 979
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>> _______________________________________________ Users mailing list
>>>> Users at lists.opensips.org http://lists.opensips.org/cgi-
>>>> bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________ Users mailing list
>>> Users at lists.opensips.org http://lists.opensips.org/cgi-
>>> bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161114/42a57e4f/attachment-0001.htm>