Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Hi Răzvan. Ok. No problem. Today morning I was investigating the softphone guys (running in the same hardware as OpenSIPS) and I have seen lots of its logs. But the logs didn't presented any problem. Everything seems to be ok. Those logs showed SIP and ICE messages. Maybe I will have to use TCP dump in the hardware where the problem is happening. And investigate at TCP level. I will prepare the log that you asked me. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 De: users-boun...@lists.opensips.org <users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org> Enviado: sexta-feira, 28 de outubro de 2016 06:09 Para: users@lists.opensips.org Assunto: Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Unfortunately I have no other ideas about what you could do. You'd better ask for support from the softphone guys, to see why they are closing the connections. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com<http://www.opensips-solutions.com> Home — OpenSIPS Solutions<http://www.opensips-solutions.com/> www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 10/27/2016 08:48 PM, Rodrigo Pimenta Carvalho wrote: Hi. Răzvan. Thank you very much! So, I will keep using the flag "Pp" to create dialogs. As I understood, it will not cause any problem. Yes, it is the client that closes the connection, always. After some more investigation, I have discovered the following specific situation: When softphone A (which is always using ICE and STUN) calls B, if B is not using ICE and STUN, the TCP connection between A and OpenSIPS remains stable. However, in this scenario, if B is using ICE and STUN, A closes the TCP connection to OpenSIPS after 33 seconds of dialog. Here, SIP is over TCP and ICE uses UDP. A and OpenSIPS run in the same hardware. So, there is no NAT between A and OpenSIPS. B run in another hardware, but in the same local network (same network domain). So, there is no NAT between B and OpenSIPS. A is a proprietary softphone and B is Microsip. I have looked at the proprietary softphone log and there is no issues with SIP. Do you have some more hint about what to investigate next? Any hint will be very helpful!! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 De: users-boun...@lists.opensips.org<mailto:users-boun...@lists.opensips.org> <users-boun...@lists.opensips.org><mailto:users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org><mailto:raz...@opensips.org> Enviado: quinta-feira, 27 de outubro de 2016 05:47 Para: users@lists.opensips.org<mailto:users@lists.opensips.org> Assunto: Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Hi, Rodrigo! See my answers inline. BR Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com<http://www.opensips-solutions.com> Home — OpenSIPS Solutions<http://www.opensips-solutions.com/> www.opensips-solutions.com<http://www.opensips-solutions.com> OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 10/26/2016 08:15 PM, Rodrigo Pimenta Carvalho wrote: Hi Răzvan. Thank you very much. I'm facing a problem here related to TCP connection teared down during dialogs. While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all the time. However, when such peer enters in a conversation (be part of a dialog), after few minutes there is a EOF received in a socket. After this, OpenSIPS can no more send SIP BYEs to the respective peer. In the log I can see: Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read: EOF on 0x74e3d048, FD 24 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read_req: EOF received Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 24, 0, 0x10,0x3) fd_no=3 called Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: releasing con 0x74e3d048, state -1, fd=-1, id=3 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: extra_data (nil) Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:tcpconn_destroy: destroying
Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Unfortunately I have no other ideas about what you could do. You'd better ask for support from the softphone guys, to see why they are closing the connections. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/27/2016 08:48 PM, Rodrigo Pimenta Carvalho wrote: Hi. Răzvan. Thank you very much! So, I will keep using the flag "Pp" to create dialogs. As I understood, it will not cause any problem. Yes, it is the client that closes the connection, always. After some more investigation, I have discovered the following specific situation: When softphone A (which is always using ICE and STUN) calls B, if B is not using ICE and STUN, the TCP connection between A and OpenSIPS remains stable. However, in this scenario, if B is using ICE and STUN, A closes the TCP connection to OpenSIPS after 33 seconds of dialog. Here, SIP is over TCP and ICE uses UDP. A and OpenSIPS run in the same hardware. So, there is no NAT between A and OpenSIPS. B run in another hardware, but in the same local network (same network domain). So, there is no NAT between B and OpenSIPS. A is a proprietary softphone and B is Microsip. I have looked at the proprietary softphone log and there is no issues with SIP. Do you have some more hint about what to investigate next? Any hint will be very helpful!! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 *De:* users-boun...@lists.opensips.org <users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org> *Enviado:* quinta-feira, 27 de outubro de 2016 05:47 *Para:* users@lists.opensips.org *Assunto:* Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Hi, Rodrigo! See my answers inline. BR Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home — OpenSIPS Solutions <http://www.opensips-solutions.com/> www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 10/26/2016 08:15 PM, Rodrigo Pimenta Carvalho wrote: Hi Răzvan. Thank you very much. I'm facing a problem here related to TCP connection teared down during dialogs. While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all the time. However, when such peer enters in a conversation (be part of a dialog), after few minutes there is a EOF received in a socket. After this, OpenSIPS can no more send SIP BYEs to the respective peer. In the log I can see: Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read: EOF on 0x74e3d048, FD 24 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read_req: EOF received Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 24, 0, 0x10,0x3) fd_no=3 called Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: releasing con 0x74e3d048, state -1, fd=-1, id=3 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: extra_data (nil) Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:tcpconn_destroy: destroying connection 0x74e3d048, flags 0006 ... When OpenSIPS try to send a SIP BYE via socket 0x74e3d048 , I can see the log: Jan 02 01:40:49 colibri-imx6-jfl opensips[21018]: Jan 2 01:40:49 [21026] DBG:core:proto_tcp_send: no open tcp connection found, opening new one, async = 1 I have already used the flag "Pp" in the creation of dialogs, but it didn't take effect. That is, even with "Pp" I'm still getting "EOF" in the TCP socket. 1 - Should the flag "Pp" avoid those EOFs during dialogs? Ideally, it should. However if the client does not "like" the pinging and closes the connection, there's not that much we can do. That flag causes the OpenSIPS to send SIP OPTIONS. The peers are replying with SIP 500. That's not really an issue. The SIP OPTIONs pinging has two purposes: 1. verify if the dialog is still active, and 2. keep the NAT pinhole open. If the SIP client doesn't know how to reply to in-dialog pinging, then 1. isn't really useful. So the reply code doesn't really matter, unless it is a 408, which means that the peer did not respond at all, and the dialog will be turn down. 2- Is a SIP 500 reply enough to OpenSIPS keep the dialog connected? Any communication between OpenSIPS and the client keeps the NAT pinhole open (see 2. above). From SIP per
Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Hi. Răzvan. Thank you very much! So, I will keep using the flag "Pp" to create dialogs. As I understood, it will not cause any problem. Yes, it is the client that closes the connection, always. After some more investigation, I have discovered the following specific situation: When softphone A (which is always using ICE and STUN) calls B, if B is not using ICE and STUN, the TCP connection between A and OpenSIPS remains stable. However, in this scenario, if B is using ICE and STUN, A closes the TCP connection to OpenSIPS after 33 seconds of dialog. Here, SIP is over TCP and ICE uses UDP. A and OpenSIPS run in the same hardware. So, there is no NAT between A and OpenSIPS. B run in another hardware, but in the same local network (same network domain). So, there is no NAT between B and OpenSIPS. A is a proprietary softphone and B is Microsip. I have looked at the proprietary softphone log and there is no issues with SIP. Do you have some more hint about what to investigate next? Any hint will be very helpful!! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 De: users-boun...@lists.opensips.org <users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org> Enviado: quinta-feira, 27 de outubro de 2016 05:47 Para: users@lists.opensips.org Assunto: Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Hi, Rodrigo! See my answers inline. BR Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com<http://www.opensips-solutions.com> Home — OpenSIPS Solutions<http://www.opensips-solutions.com/> www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 10/26/2016 08:15 PM, Rodrigo Pimenta Carvalho wrote: Hi Răzvan. Thank you very much. I'm facing a problem here related to TCP connection teared down during dialogs. While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all the time. However, when such peer enters in a conversation (be part of a dialog), after few minutes there is a EOF received in a socket. After this, OpenSIPS can no more send SIP BYEs to the respective peer. In the log I can see: Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read: EOF on 0x74e3d048, FD 24 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read_req: EOF received Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 24, 0, 0x10,0x3) fd_no=3 called Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: releasing con 0x74e3d048, state -1, fd=-1, id=3 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: extra_data (nil) Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:tcpconn_destroy: destroying connection 0x74e3d048, flags 0006 ... When OpenSIPS try to send a SIP BYE via socket 0x74e3d048 , I can see the log: Jan 02 01:40:49 colibri-imx6-jfl opensips[21018]: Jan 2 01:40:49 [21026] DBG:core:proto_tcp_send: no open tcp connection found, opening new one, async = 1 I have already used the flag "Pp" in the creation of dialogs, but it didn't take effect. That is, even with "Pp" I'm still getting "EOF" in the TCP socket. 1 - Should the flag "Pp" avoid those EOFs during dialogs? Ideally, it should. However if the client does not "like" the pinging and closes the connection, there's not that much we can do. That flag causes the OpenSIPS to send SIP OPTIONS. The peers are replying with SIP 500. That's not really an issue. The SIP OPTIONs pinging has two purposes: 1. verify if the dialog is still active, and 2. keep the NAT pinhole open. If the SIP client doesn't know how to reply to in-dialog pinging, then 1. isn't really useful. So the reply code doesn't really matter, unless it is a 408, which means that the peer did not respond at all, and the dialog will be turn down. 2- Is a SIP 500 reply enough to OpenSIPS keep the dialog connected? Any communication between OpenSIPS and the client keeps the NAT pinhole open (see 2. above). From SIP perspective, that 500 could have a lot of meanings: the client does not know how to reply, or there was an internal error that could not process the message. However, this whole communication will keep the connection alive. 3 - Does it make sense getting absence of keep alive messages during dialogs? So as I said abov
Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Hi, Rodrigo! See my answers inline. BR Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/26/2016 08:15 PM, Rodrigo Pimenta Carvalho wrote: Hi Răzvan. Thank you very much. I'm facing a problem here related to TCP connection teared down during dialogs. While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all the time. However, when such peer enters in a conversation (be part of a dialog), after few minutes there is a EOF received in a socket. After this, OpenSIPS can no more send SIP BYEs to the respective peer. In the log I can see: Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read: EOF on 0x74e3d048, FD 24 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read_req: EOF received Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 24, 0, 0x10,0x3) fd_no=3 called Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: releasing con 0x74e3d048, state -1, fd=-1, id=3 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: extra_data (nil) Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:tcpconn_destroy: destroying connection 0x74e3d048, flags 0006 ... When OpenSIPS try to send a SIP BYE via socket 0x74e3d048 , I can see the log: Jan 02 01:40:49 colibri-imx6-jfl opensips[21018]: Jan 2 01:40:49 [21026] DBG:core:proto_tcp_send: no open tcp connection found, opening new one, async = 1 I have already used the flag "Pp" in the creation of dialogs, but it didn't take effect. That is, even with "Pp" I'm still getting "EOF" in the TCP socket. 1 - Should the flag "Pp" avoid those EOFs during dialogs? Ideally, it should. However if the client does not "like" the pinging and closes the connection, there's not that much we can do. That flag causes the OpenSIPS to send SIP OPTIONS. The peers are replying with SIP 500. That's not really an issue. The SIP OPTIONs pinging has two purposes: 1. verify if the dialog is still active, and 2. keep the NAT pinhole open. If the SIP client doesn't know how to reply to in-dialog pinging, then 1. isn't really useful. So the reply code doesn't really matter, unless it is a 408, which means that the peer did not respond at all, and the dialog will be turn down. 2- Is a SIP 500 reply enough to OpenSIPS keep the dialog connected? Any communication between OpenSIPS and the client keeps the NAT pinhole open (see 2. above). From SIP perspective, that 500 could have a lot of meanings: the client does not know how to reply, or there was an internal error that could not process the message. However, this whole communication will keep the connection alive. 3 - Does it make sense getting absence of keep alive messages during dialogs? So as I said above, any pinging method is useful to keep the connection alive. Regarding the dialogs, there is no special need for pinging from SIP perspective, unless you are using SST, which I presume you are not. Any hint will be very helpful! P.S.: I will check the TCP trace too, looking for keep alives. From your diagnosis, I understand that the client closes the connection, right? Unfortunately I don't know why it does that, perhaps the best thing to do is to check the client's logs. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 *De:* users-boun...@lists.opensips.org <users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org> *Enviado:* quarta-feira, 26 de outubro de 2016 13:08 *Para:* users@lists.opensips.org *Assunto:* Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Hi, Rodrigo! The logs you are tracing are printed when OpenSIPS receives something from the client, and then immediately responds back. Due to the fact that we don't see any other debug messages, like SIP parsing & stuff, makes me think that it is a CRLF pinging - the client periodically sends a CRLFCRLF TCP message to OpenSIPS, and OpenSIPS responds with a single CRLF. Note that this is different from a TCP keep-alive, where each peer send a 0-length TCP message, without any body. That message doesn't even get to the application layer. However, tracing the communication between OpenSIPS and the client should confirm the above :). Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home — OpenSIPS Solutions <http://www.opensips-solutions.com/> ww
Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Hi Răzvan. Thank you very much. I'm facing a problem here related to TCP connection teared down during dialogs. While a peer is not in dialogs, its TCP connection to OpenSIPS keeps online all the time. However, when such peer enters in a conversation (be part of a dialog), after few minutes there is a EOF received in a socket. After this, OpenSIPS can no more send SIP BYEs to the respective peer. In the log I can see: Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read: EOF on 0x74e3d048, FD 24 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcp_read_req: EOF received Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 24 (0x1875e8, 24, 0, 0x10,0x3) fd_no=3 called Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: releasing con 0x74e3d048, state -1, fd=-1, id=3 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21027] DBG:core:tcpconn_release: extra_data (nil) Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:handle_tcp_worker: reader response= 74e3d048, -1 from 2 Jan 02 01:38:45 colibri-imx6-jfl opensips[21018]: Jan 2 01:38:45 [21029] DBG:core:tcpconn_destroy: destroying connection 0x74e3d048, flags 0006 ... When OpenSIPS try to send a SIP BYE via socket 0x74e3d048 , I can see the log: Jan 02 01:40:49 colibri-imx6-jfl opensips[21018]: Jan 2 01:40:49 [21026] DBG:core:proto_tcp_send: no open tcp connection found, opening new one, async = 1 I have already used the flag "Pp" in the creation of dialogs, but it didn't take effect. That is, even with "Pp" I'm still getting "EOF" in the TCP socket. 1 - Should the flag "Pp" avoid those EOFs during dialogs? That flag causes the OpenSIPS to send SIP OPTIONS. The peers are replying with SIP 500. 2- Is a SIP 500 reply enough to OpenSIPS keep the dialog connected? 3 - Does it make sense getting absence of keep alive messages during dialogs? Any hint will be very helpful! P.S.: I will check the TCP trace too, looking for keep alives. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 De: users-boun...@lists.opensips.org <users-boun...@lists.opensips.org> em nome de Răzvan Crainea <raz...@opensips.org> Enviado: quarta-feira, 26 de outubro de 2016 13:08 Para: users@lists.opensips.org Assunto: Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS? Hi, Rodrigo! The logs you are tracing are printed when OpenSIPS receives something from the client, and then immediately responds back. Due to the fact that we don't see any other debug messages, like SIP parsing & stuff, makes me think that it is a CRLF pinging - the client periodically sends a CRLFCRLF TCP message to OpenSIPS, and OpenSIPS responds with a single CRLF. Note that this is different from a TCP keep-alive, where each peer send a 0-length TCP message, without any body. That message doesn't even get to the application layer. However, tracing the communication between OpenSIPS and the client should confirm the above :). Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com<http://www.opensips-solutions.com> Home — OpenSIPS Solutions<http://www.opensips-solutions.com/> www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 10/26/2016 05:10 PM, Rodrigo Pimenta Carvalho wrote: Dear OpenSIPS users, In the OpenSIPS log I see: Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_read_req: Using the global ( per process ) buff Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_handle_req: content-length= 0 Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:async_tsend_stream: Async successful write from first try on 0x74e13548 Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_read_req: tcp_read_req end The frequency is 1 time at each 1,5 minute. There is only one client online. I suspect that OpenSIPS uses the socket 0x74e13548 to send messages to such client. The client became online using TCP. Just to confirm, is this log a result of a TCP keep alive function enabled? Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ___ Users mailing list Users@lists.opensips.org<mailto: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
Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?
Hi, Rodrigo! The logs you are tracing are printed when OpenSIPS receives something from the client, and then immediately responds back. Due to the fact that we don't see any other debug messages, like SIP parsing & stuff, makes me think that it is a CRLF pinging - the client periodically sends a CRLFCRLF TCP message to OpenSIPS, and OpenSIPS responds with a single CRLF. Note that this is different from a TCP keep-alive, where each peer send a 0-length TCP message, without any body. That message doesn't even get to the application layer. However, tracing the communication between OpenSIPS and the client should confirm the above :). Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/26/2016 05:10 PM, Rodrigo Pimenta Carvalho wrote: Dear OpenSIPS users, In the OpenSIPS log I see: Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_read_req: Using the global ( per process ) buff Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_handle_req: content-length= 0 Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:async_tsend_stream: Async successful write from first try on 0x74e13548 Jan 01 19:30:38 colibri-imx6-jfl opensips[3444]: Jan 1 19:30:38 [3451] DBG:core:tcp_read_req: tcp_read_req end The frequency is 1 time at each 1,5 minute. There is only one client online. I suspect that OpenSIPS uses the socket 0x74e13548 to send messages to such client. The client became online using TCP. Just to confirm, is this log a result of a TCP keep alive function enabled? Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ___ 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
