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 <raz...@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 <raz...@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@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users@lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > _______________________________________________ > Users mailing > listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users