Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

[Răzvan Crainea]

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 
 em nome de Răzvan Crainea 


*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 
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 proce

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

[Răzvan Crainea]

Hi, Rodrigo!

Could you send me the system logs related to the BYE processing?

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 10/27/2016 10:09 PM, Rodrigo Pimenta Carvalho wrote:


Hi Razvan,

Thank you very much again!

See my comments and question in line, please.

Best regards!


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



*De:* users-boun...@lists.opensips.org 
 em nome de Răzvan Crainea 


*Enviado:* quinta-feira, 27 de outubro de 2016 05:58
*Para:* users@lists.opensips.org
*Assunto:* Re: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and 
sends INVITE, but not BYE. How to change it?

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 client will be always reachable. Because in my specific case, 
the client(which break down the TCP connection) is in the same 
hardware as OpenSIPS. So, there will not be NATs here.


 As I saw in the log, OpenSIPS reopen the connection, like this:

DBG:core:proto_tcp_send: no open tcp connection found, opening new 
one, async = 1


 And this is opened in the moment after OpenSIPS trying to pass 
the SIP BYE to the local client.
 As long as OpenSIPS is already reopening the TCP connection, when 
it needs to send the SIP BYE, why the SIP BYE is not sent finally?


 I believe that I can use such new connection to send the SIP BYE. 
In this case, I intend to force OpenSIPS to send the SIP BYE after 
reopening such TCP connection. Is it possible in terms of script?
 I have just checked my script and I'm not using the flag 
tcp_no_new_conn_bflag.



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 Solutions
www.opensips-solutions.com
Home — OpenSIPS Solutions 
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 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 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


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

[Bogdan-Andrei Iancu]

Hi Jonathan,

No, it is no yet available. Give me couple of days and I will make a 
patch for it.


Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 25.10.2016 19:22, Jonathan Hunter wrote:


Hi Bogdan,


Sorry cant recall If I replied to this.


Is cc_pos available now to extract from the module?


Thats the only thing I need then I can implement call center which I 
think will be much more scale-able than the other approach I am using 
with FreeSWITCH, I would use that just for announcements.



Any response/help appreciated.


Jon




*From:* Bogdan-Andrei Iancu 
*Sent:* 13 October 2016 10:59
*To:* Jonathan Hunter; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
Hi Jonathan,

No, currently this is not possible. I was trying to envision a 
solution for your need.


But, checking the code, it is really difficult to add the headers to 
the INVITEs originated by OpenSIPS (via the B2BUA), as we need some 
flexibility (different headers to different INVITEs belonging to the 
same B2B scenario , and even more, we need to traverse couple of 
internal APIs - to propagate the hdrs from Call center module all the 
way to TM).


So, a simpler approach may be to add such extra info as URI params to 
the RURI. Like if you have the RURI "sip:queue@192.168.1.10:5060" for 
the queue/waiting playback, the RURI in the INVITE to the media server 
will look like : sip:queue@192.168.1.10:5060;cc_eta=40;cc_pos=10 - 
cc_eta being the estimated time to wait in seconds and cc_pos the 
position in the queue.


What do you think of this ?

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 12.10.2016 17:21, Jonathan Hunter wrote:

Hi Bogdan,

Yes being able to grab the queue position would be perfect.

Is that possible?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: hunter...@hotmail.com; users@lists.opensips.org
From: bog...@opensips.org
Date: Wed, 12 Oct 2016 15:42:43 +0300

Hi Jonathan,

When a call is mapped to a flow / queue (before playing the welcome 
message), we know the ETA (estimated time to wait) and when is placed 
in the queue (before playing the queuing) we internally know the 
position in the queue.


Would it help to have the position in the queue placed into a custome 
SIP header, when sending the INVITE to the message_queue URL ? or to 
the welcome message ?


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 12.10.2016 12:06, Jonathan Hunter wrote:

Hello Bogdan,

Thanks for the response.

In terms of my question, with a number of queuing platforms, they
have the capability to tell the caller, what position they are in
, and when they are likely to be answered.

I just wondered if this logic was already within the module, or
if I would need to use an external code/script to facilitate this
function?

As I presume call_center tracks the number of calls currently in
a queue ? I would then want to be able to extract that
information, and if a caller was for example in 3rd place in a
queue, I could inject the relevant audio from freeswitch to tell
them their current position?

Does that make sense? :)   Just wanted to know if its something
this module can do?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: users@lists.opensips.org ;
hunter...@hotmail.com 
From: bog...@opensips.org 
Date: Wed, 12 Oct 2016 11:23:45 +0300

Hello Jon,

The message_queue is a SIP URI pointing to an audio announcement
to play to roll of the waiting/in-queue playback. This needs to
be an announcements that never ends (from the perspective of the
media server); only the the OpenSIPS Queue may terminate the
playback, when it decides to take out the call from waiting and
to deliver it to an agent.

As for your question, I'm not sure I understand what you mean by
"inject a message with queue position for the caller in question"
- could you detail please ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11.10.2016 13:36, Jonathan Hunter wrote:

Hi guys,

I have implemented an opensips/freeswitch environment, and I
wish to add call queues to it, and I like the look of
call_center, so just checking this out in comparison to
mod_callcenter in FS world.

My main question is if using the call_center module if you
   

Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

[Jonathan Hunter]

Hi Bogdan,


Great news, really do appreciate that.


Many thanks


Jon



From: Bogdan-Andrei Iancu 
Sent: 28 October 2016 12:48
To: Jonathan Hunter; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

Hi Jonathan,

No, it is no yet available. Give me couple of days and I will make a patch for 
it.

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

Home — OpenSIPS Solutions
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 25.10.2016 19:22, Jonathan Hunter wrote:

Hi Bogdan,


Sorry cant recall If I replied to this.


Is cc_pos available now to extract from the module?


Thats the only thing I need then I can implement call center which I think will 
be much more scale-able than the other approach I am using with FreeSWITCH, I 
would use that just for announcements.


Any response/help appreciated.


Jon



From: Bogdan-Andrei Iancu 
Sent: 13 October 2016 10:59
To: Jonathan Hunter; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position

Hi Jonathan,

No, currently this is not possible. I was trying to envision a solution for 
your need.

But, checking the code, it is really difficult to add the headers to the 
INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility 
(different headers to different INVITEs belonging to the same B2B scenario , 
and even more, we need to traverse couple of internal APIs - to propagate the 
hdrs from Call center module all the way to TM).

So, a simpler approach may be to add such extra info as URI params to the RURI. 
Like if you have the RURI 
"sip:queue@192.168.1.10:5060" for the 
queue/waiting playback, the RURI in the INVITE to the media server will look 
like :  
sip:queue@192.168.1.10:5060;cc_eta=40;cc_pos=10
  - cc_eta being the estimated time to wait in seconds and cc_pos the position 
in the queue.

What do you think of this ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 12.10.2016 17:21, Jonathan Hunter wrote:
Hi Bogdan,

Yes being able to grab the queue position would be perfect.

Is that possible?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: hunter...@hotmail.com; 
users@lists.opensips.org
From: bog...@opensips.org
Date: Wed, 12 Oct 2016 15:42:43 +0300

Hi Jonathan,

When a call is mapped to a flow / queue (before playing the welcome message), 
we know the ETA (estimated time to wait) and when is placed in the queue 
(before playing the queuing) we internally know the position in the queue.

Would it help to have the position in the queue placed into a custome SIP 
header, when sending the INVITE to the message_queue URL ? or to the welcome 
message ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 12.10.2016 12:06, Jonathan Hunter wrote:
Hello Bogdan,

Thanks for the response.

In terms of my question, with a number of queuing platforms, they have the 
capability to tell the caller, what position they are in , and when they are 
likely to be answered.

I just wondered if this logic was already within the module, or if I would need 
to use an external code/script to facilitate this function?

As I presume call_center tracks the number of calls currently in a queue ? I 
would then want to be able to extract that information, and if a caller was for 
example in 3rd place in a queue, I could inject the relevant audio from 
freeswitch to tell them their current position?

Does that make sense? :)   Just wanted to know if its something this module can 
do?

Thanks

Jon


Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position
To: users@lists.opensips.org; 
hunter...@hotmail.com
From: bog...@opensips.org
Date: Wed, 12 Oct 2016 11:23:45 +0300

Hello Jon,

The message_queue is a SIP URI pointing to an audio announcement to play to 
roll of the waiting/in-queue playback. This needs to be an announcements that 
never ends (from the perspective of the media server); only the the OpenSIPS 
Queue may terminate the playback, when it decides to take out the call from 
waiting and to deliver it to an agent.

As for your question, I'm not sure I understand what you mean by "inject a 
message with queue position for the caller in question" - could you detail 
please

Re: [OpenSIPS-Users] Is it a kind of TCP keep alive produced by OpenSIPS?

[Rodrigo Pimenta Carvalho]

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  em nome 
de Răzvan Crainea 
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

Home — OpenSIPS Solutions
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 
 em 
nome de Răzvan Crainea 
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
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: