Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

2015-09-05 Thread Matt Hamilton 

Hi Bogdan,


We have been using force_send_socket before calling t_relay to manually set the 
outbound interface (out of a couple of interfaces), so it was done for all the 
messages (not only for initial INVITE). Not sure if this was the right way to 
do it, but it has worked in 1.7.1. When we decided to use TLS recently, we also 
decided to to upgrade to 1.11. In our script, force_send_socket is called 
without explicitly specifying the port and proto. When those are not specified, 
in 1.7.1,  messages marked with tls are sent encrypted, whereas in 1.11 they 
are sent unencrypted (which the phones didn't like).


Anyway, passing the port and proto to force_send_socket took care of it. The 
more interesting thing we noticed is that the system also worked when we remove 
the force_send_sockets from the script completely. We will do more tests, and 
try to remember why the force_send_sockets were put in the script in the first 
place.


Matt



From: Bogdan-Andrei Iancu 
Sent: Friday, September 4, 2015 11:56 AM
To: users@lists.opensips.org; mistral9...@hotmail.com
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

You mean the force_send_socket() you do for the initial INVITE ? or ?

Regards,

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

On 03.09.2015 17:19, Matt Hamilton wrote:


Hi Bogdan,

This issue is seems to be related to force_send_socket which behaves 
differently in 1.11 vs 1.7.  To make it work, I had to explicitly specify the 
port and and the proto (for force_send_socket) based on "transport=tls" 
statement and the direction of the traffic.

Matt



From: Bogdan-Andrei Iancu 
Sent: Monday, August 31, 2015 4:19 PM
To: OpenSIPS users mailling list; Matt Hamilton
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

Indeed, the SIP messages do look ok.

Could you post the OpenSIPS logs (in debug 4) for processing the NOTIFY request 
?

Regards,

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

On 31.08.2015 20:07, Matt Hamilton wrote:

Hi Bogdan,


Pastebin link is http://pastebin.com/tM7zqTKX


I included both 1.7.1 and 1.11 captures. I don't see a difference between them 
other than 1.11 sending the NOTIFY to UAC unencrypted.

Btw, INVITEs seems to be behaving the same way as NOTIFY (don't have a capture 
for those - I assume the issue is the same).


Btw, TLS works fine between Opensips 1.11 and the phone (OK messages, etc. are 
encrypted).


Thanks,

Matt


[http://pastebin.com/i/fb2.jpg]

Opensips TLS - Pastebin.com
Read more...



From: Bogdan-Andrei Iancu 
Sent: Monday, August 31, 2015 5:21 AM
To: OpenSIPS users mailling list; 
mistral9...@hotmail.com
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

Can you post of pastebin (or similar) the SIP capture showing the incoming 
NOTIFY (via UDP) from Asterisk and the outgoing NOTIFY (supposedly via TLS) to 
UAC ?
Also the SUBSCRIBE request going from OpenSIPS to Asterisk will help alot.

Regards,

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

On 30.08.2015 18:22, Matt Hamilton wrote:


We use Opensips (with TLS) as a dispatcher to multiple Asterisk servers.  
Currently we are in the process of upgrading from 1.7.1 to 1.11.5, and we ran 
into a discrepancy between 1.7.1 and 1.11.5 regarding SIP NOTIFY messages.


Here is the flow (both ways):

UAC(TLS) -> Opensips   (UDP)-> Asterisk
Asterisk (UDP) -> Opensips   (TLS)->UAC


In 1.7.1,  all messages between Opensips and UAC were encrypted - didn't matter 
if it was originated at UAC or Asterisk.

In 1.11.5, the SIP NOTIFY messages coming from Asterisk are sent to UAC 
unencrypted (and not accepted by UAC). Here is the request that Opensips 
receives and sends to the UAC in plaintext:

Request-Line: NOTIFY 
sip:101@1.2.3.4:5075;transport=tls;nat=yes
 SIP/2.0

Anything we can do to have that leg encrypted as well?

Thanks,
Matt




___
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


___
Users mailing list
Users@lists.opensips.org
http://

[OpenSIPS-Users] webrtc support

2015-09-05 Thread Terrance Devor 
Hello Everyone,

As the the server side is stable and far end nat is implemented, we are now
looking to include the webrtc stack on top. From what I can see there will
be:

* OpenSIPS+OverSIP on the server side

On the client side I am unclear on a few things. Is it best to go with
jssip + sipml5 or pjsip with webrtc component (ie, csimple). What is your
experience with attempting this stack. Anything proven to work and stable?

Thanks in Advance,

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

Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

2015-09-05 Thread Matt Hamilton 

Hi Bogdan,


We have been using force_send_socket before calling t_relay to manually set the 
outbound interface (out of a couple of interfaces), so it was done for all the 
messages (not only for initial INVITE). Not sure if this was the right way to 
do it, but it has worked in 1.7.1. When we decided to use TLS recently, we also 
decided to to upgrade to 1.11. In our script, force_send_socket is called 
without explicitly specifying the port and proto. When those are not specified, 
in 1.7.1,  messages marked with tls are sent encrypted, whereas in 1.11 they 
are sent unencrypted (which the phones didn't like).


Anyway, passing the port and proto to force_send_socket took care of it. The 
more interesting thing we noticed is that the system also worked when we remove 
the force_send_sockets from the script completely. We will do more tests, and 
try to remember why the force_send_sockets were put in the script in the first 
place.


Matt



From: Bogdan-Andrei Iancu 
Sent: Friday, September 4, 2015 11:56 AM
To: users@lists.opensips.org; mistral9...@hotmail.com
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

You mean the force_send_socket() you do for the initial INVITE ? or ?

Regards,

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

On 03.09.2015 17:19, Matt Hamilton wrote:


Hi Bogdan,

This issue is seems to be related to force_send_socket which behaves 
differently in 1.11 vs 1.7.  To make it work, I had to explicitly specify the 
port and and the proto (for force_send_socket) based on "transport=tls" 
statement and the direction of the traffic.

Matt



From: Bogdan-Andrei Iancu 
Sent: Monday, August 31, 2015 4:19 PM
To: OpenSIPS users mailling list; Matt Hamilton
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

Indeed, the SIP messages do look ok.

Could you post the OpenSIPS logs (in debug 4) for processing the NOTIFY request 
?

Regards,

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

On 31.08.2015 20:07, Matt Hamilton wrote:

Hi Bogdan,


Pastebin link is http://pastebin.com/tM7zqTKX


I included both 1.7.1 and 1.11 captures. I don't see a difference between them 
other than 1.11 sending the NOTIFY to UAC unencrypted.

Btw, INVITEs seems to be behaving the same way as NOTIFY (don't have a capture 
for those - I assume the issue is the same).


Btw, TLS works fine between Opensips 1.11 and the phone (OK messages, etc. are 
encrypted).


Thanks,

Matt


[http://pastebin.com/i/fb2.jpg]

Opensips TLS - Pastebin.com
Read more...



From: Bogdan-Andrei Iancu 
Sent: Monday, August 31, 2015 5:21 AM
To: OpenSIPS users mailling list; 
mistral9...@hotmail.com
Subject: Re: [OpenSIPS-Users] TLS discrepancy between 1.7.1 and 1.11.5

Hi Matt,

Can you post of pastebin (or similar) the SIP capture showing the incoming 
NOTIFY (via UDP) from Asterisk and the outgoing NOTIFY (supposedly via TLS) to 
UAC ?
Also the SUBSCRIBE request going from OpenSIPS to Asterisk will help alot.

Regards,

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

On 30.08.2015 18:22, Matt Hamilton wrote:


We use Opensips (with TLS) as a dispatcher to multiple Asterisk servers.  
Currently we are in the process of upgrading from 1.7.1 to 1.11.5, and we ran 
into a discrepancy between 1.7.1 and 1.11.5 regarding SIP NOTIFY messages.


Here is the flow (both ways):

UAC(TLS) -> Opensips   (UDP)-> Asterisk
Asterisk (UDP) -> Opensips   (TLS)->UAC


In 1.7.1,  all messages between Opensips and UAC were encrypted - didn't matter 
if it was originated at UAC or Asterisk.

In 1.11.5, the SIP NOTIFY messages coming from Asterisk are sent to UAC 
unencrypted (and not accepted by UAC). Here is the request that Opensips 
receives and sends to the UAC in plaintext:

Request-Line: NOTIFY 
sip:101@1.2.3.4:5075;transport=tls;nat=yes
 SIP/2.0

Anything we can do to have that leg encrypted as well?

Thanks,
Matt




___
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


___
Users mailing list
Users@lists.opensips.org
http://

Re: [OpenSIPS-Users] core generated by opensips

2015-09-05 Thread Gupta, Rahul 
Hi Vlad, thanks for debugging the issue on our server, I appreciate your 
valuable time. I have enabled memory debugging and waiting for the issue to 
happen.

Meanwhile I have uploaded the gdb traces for the deadlock issue which caused 
100% cps you have looked at another server. The link to github issue is github: 
 https://github.com/OpenSIPS/opensips/issues/630


Thanks
Rahul Gupta

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Vlad Paiu
Sent: Friday, September 04, 2015 11:59 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] core generated by opensips

Hello,

As per our meeting today, please enable memory debugging on your server, and 
let me know when another crash happens, so I can take a look at the newly 
generated core file.

Regards,


Vlad Paiu

OpenSIPS Developer

http://www.opensips-solutions.com
On 03.09.2015 17:02, Vlad Paiu wrote:
Hello,

Can you replicate the crash on demand, or does it happen randomly ?
Would you be able to provide access to a server containing the core file and 
the OpenSIPS binary, in order to speed-up the debugging process ( avoid the 
ping pong on the mailing list ) ?

Regards,


Vlad Paiu

OpenSIPS Developer

http://www.opensips-solutions.com
On 02.09.2015 18:47, Gupta, Rahul wrote:
Hi Bogdan, any update on this ?

From: Gupta, Rahul
Sent: Monday, August 31, 2015 4:42 PM
To: 'Bogdan-Andrei Iancu'; OpenSIPS users mailling list
Subject: RE: [OpenSIPS-Users] core generated by opensips

Hi Bogdan, following is the info you requested.

#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x004b12e9 in tcp_init_children (chd_rank=, 
startup_done=0x0) at tcp_main.c:2389
#8  0x0043aebf in main_loop (argc=, argv=) at main.c:1011
#9  main (argc=, argv=) at main.c:1612
(gdb) f 3
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
597 tcp_read.c: No such file or directory.
in tcp_read.c
(gdb) p con->con_req
$1 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p ¤t_req
$2 = (struct tcp_req *) 0x82d720
(gdb) p req
$3 = (struct tcp_req *) 0x7f20931a97e0
(gdb) p *con
$4 = {s = 30, fd = 21, write_lock = 0, id = 19, rcv = {src_ip = {af = 2, len = 
4, u = {addrl = {2621885450, 0}, addr32 = {2621885450, 0, 0, 0}, addr16 = 
{52234, 40006, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\234", '\000' }}, dst_ip = {af = 2, 
len = 4, u = {addrl = {2588331018, 0}, addr32 = {2588331018, 0, 0, 0}, addr16 = 
{52234, 39494, 0, 0, 0, 0, 0, 0},
addr = "\n\314F\232", '\000' }}, src_port = 5060, 
dst_port = 5070, proto = 2, proto_reserved1 = 19, proto_reserved2 = 0, src_su = 
{s = {sa_family = 2,
sa_data = "\023\304\n\314F\234\000\000\000\000\000\000\000"}, sin = 
{sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 2621885450}, sin_zero = 
"\000\000\000\000\000\000\000"}},
bind_address = 0x7f2093171398}, refcnt = 2, type = PROTO_TCP, flags = 2, 
state = S_CONN_CONNECT, extra_data = 0x0, timeout = 50039, lifetime = 0, 
id_hash = 19, id_next = 0x0, id_prev = 0x0, c_next = 0x0,
  c_prev = 0x0, con_aliases = {{parent = 0x7f2081a933c0, next = 0x0, prev = 
0x0, port = 5060, hash = 974}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0,
  port = 0, hash = 0}, {parent = 0x0, next = 0x0, prev = 0x0, port = 0, 
hash = 0}}, aliases = 1, con_req = 0x7f20931a97e0, msg_attempts = 1, 
async_chunks = 0x7f2081a93530, async_chunks_no = 0,
  oldest_chunk = 0}
(gdb)

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Monday, August 31, 2015 4:39 PM
To: Gupta, Rahul; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] core generated by opensips

And printing :
*con

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 31.08.2015 22:50, Gupta, Rahul wrote:
Hi Bogdan, following is the info you requested. This is not the first tcp read, 
this server is been running for a while and taking calls.

(gdb) bt
#0  0x7f2095572e2c in vfprintf () from /lib64/libc.so.6
#1  0x7f209560fed0 in __vsyslog_chk () from /lib64/libc.so.6
#2  0x7f2095610100 in syslog () from /lib64/libc.so.6
#3  0x004c4202 in tcp_read_req (con=0x7f2081a933c0, 
bytes_read=0x7ffc6bc97f0c) at tcp_read.c:597
#4  0x004c5908 in handle_io (fm=, idx=-1, 
event_type=) at tcp_read.c:1033
#5  0x004c8083 in io_wait_loop_epoll (unix_sock=) 
at io_wait.h:845
#6  tcp_receive_loop (unix_sock=) at tcp_read.c:1141
#7  0x