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 <fedo...@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 <raz...@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 <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 >> 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