date:20180618

Re: [OpenSIPS-Users] mid_registrar remove all bindings

2018-06-18 Thread Alexey Kazantsev via Users

Hello.

Is possible at all to have an asterisk sign instead of valid URI?

I re-read RFC and havent' found anything like that.

https://tools.ietf.org/html/rfc3261#section-8.1.1.8

---
BR, Alexey
http://alexeyka.zantsev.com/
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] sst module : update method instead of invite

2018-06-18 Thread Abdoul Osséni

Hello group,

Is is possible to configure sst module to send update method intead invite
method?
Why? because a gateway does not support in dialog INVITE but only INVITE.

Thanks.

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

Re: [OpenSIPS-Users] Intermittent TLS Problem -

2018-06-18 Thread Callum Guy

Hi All,

Further to this issue I have established that the fault occurs when the
server does not provide a finish "Encrypted Handshake Message" following
key/cert exchange.

Based on my test patterns it seems to indicate that this improves *slightly*
over time meaning that its gets a bit more reliable after a few calls have
been processed by the remote. This doesn't mean that the calls don't ever
fail though, it goes from 50% failure rate to 20% perhaps.

Does anyone have confidence that this indicates a fault with the remote
system rather than the OpenSIPs implementation?

Thanks

On Mon, Jun 18, 2018 at 1:15 PM Callum Guy  wrote:

> Hi All,
>
> I'm running a TLS protected service using OpenSIPs 2.3.3
> and openssl-1.0.2k-12.el7.x86_64 on a CentOS 7.5 server. RTPProxy is in
> place to forward all the media on every call.
>
> OpenSIPs is acting as a proxy to an internal FreeSWITCH instance and
> handling all inbound and outbound TLS negotiation.
>
> The call scenario is:
> Leg A: carrier -> opensips -> freeswitch (answer)
> Leg B: freeswitch -> opensips ->carrier
>
> I have a situation where calls sometimes fail during TLS negotiation on
> the B leg. The exact same call will work only seconds before and then the
> subsequent call will fail. This is still a test service so there is no
> traffic on the platform which would effect the calls.
>
> The destination carrier is Twilio where we are targeting a custom domain
> which provides three separate fallback IP's. The logs (below) show each
> being attempted in sequence and OpenSIPs is reporting failure.
>
> I have a packet capture (SIP encrypted) which shows that the carrier
> (Twilio) are setting up the connection and attempting to change the cipher
> spec, from my understanding it looks like this is what triggers the errors
> in OpenSIPs which then returns a SIP packet to Twilio before trying the
> next IP in the list (see screen shot below).
>
> When viewing the packet capture on a call which was not affected I don't
> see wireshark reporting "Change Cipher Spec" from the carrier network so at
> present this is the main suspicion. Unfortunately this is as far as my
> current understanding can take me so while i continue to research i wanted
> to reach out to see is anyone in the community can help! Let me know if I
> can provide any further information.
>
> Thanks!
>
> *OpenSIPs Log*
>
> Jun 18 11:20:33 opensips[6373]: INFO: [INVITE] (outbound) REST response:
> RU: sip:+35361234567 <+353%2061%20234%20567>
> @custom.pstn.ie1.twilio.com:5061;transport=tls DU: sip:
> custom.pstn.ie1.twilio.com:5061 FU: "+4940261234567 <+49%2040%20261234567>"
>  ps:+4940261234567@172.20.0.101> 
> To(sip:35361234567@172.18.0.110:5061;transport=tls)
> From(sip:+40261234567@172.20.0.101)
> ID:137a5be9-ed84-1236-10aa-d0431e9b59cf
> Jun 18 11:20:33 opensips[6373]: INFO:core:probe_max_sock_buff: using snd
> buffer of 416 kb
> Jun 18 11:20:33 opensips[6373]: INFO:core:init_sock_keepalive: TCP
> keepalive enabled on socket 29
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 2
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 1
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 0
> Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> *Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:tls_blocking_write: TLS
> send timeout (60)*
> *Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:proto_tls_send: failed to
> send*
> *Jun 18 11:20:34 opensips[6373]: ERROR:tm:msg_send: send()
> to 54.171.127.194:5061  for proto tls/3 failed*
> *Jun 18 11:20:34 opensips[6373]: ERROR:tm:t_forward_nonack: sending
> request failed*
> Jun 18 11:20:34 opensips[6373]: INFO:core:probe_max_sock_buff: using snd
> buffer of 416 kb
> Jun 18 11:20:34 opensips[6373]: INFO:core:init_sock_keepalive: TCP
> keepalive enabled on socket 29
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 2
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 1
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 0
> Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
> is good: verify return: 1
> *Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:tls_blocking_write: TLS
> send timeout (60)*
> *Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:proto_tls_send: failed to
> send*
> *Jun 18 11:20:34 opensips[6373]: ERROR:tm:msg_send: send()
> to 54.171.127.193:5061  for proto

Re: [OpenSIPS-Users] sipcapture segfaults when capturing on raw interface in all 2.x versions of opensips

2018-06-18 Thread Michael Ulitskiy

Bogdan,

These are not hep packets. i'm using raw capture.
Cisco switch is configuted with RSPAN and delivers sip traffic to capture 
server on a particular vlan (vlan 990 in this case).
The config is simplest possible:

memlog=0
debug_mode=1
listen=udp:127.0.0.1:5060
listen=hep_udp:127.0.0.1:9063
children=5
dns=no
mpath="/usr/local/opensips/lib/opensips/modules"  #path to modules
db_default_url="postgres://:@localhost:5432/sipcapture"

loadmodule "proto_hep.so"
loadmodule "proto_udp.so"
loadmodule "db_postgres.so"
modparam("db_postgres", "exec_query_threshold", 10)
loadmodule "sipmsgops.so"
loadmodule "sipcapture.so"
modparam("sipcapture", "db_url", 
"postgres://:@localhost:5432/sipcapture")
#modparam("sipcapture", "table_name", "sip_capture")
modparam("sipcapture", "hep_capture_on", 1)
modparam("sipcapture", "raw_moni_capture_on", 1)
modparam("sipcapture", "raw_interface", "bond0.990")
modparam("sipcapture", "promiscious_on", 1)
modparam("sipcapture", "raw_socket_listen", "10.0.0.1:5060-5160")
modparam("sipcapture", "raw_moni_bpf_on", 1)
modparam("sipcapture", "capture_on", 1)

route {
if (!is_method("OPTIONS|REGISTER|NOTIFY|SUBSCRIBE")) {
sip_capture("sip_capture");
}
}
 
onreply_route {
if (!is_method("OPTIONS|REGISTER|NOTIFY|SUBSCRIBE")) {
sip_capture("sip_capture");
}
}

I'm not sure hot to isolate the particular packet that causes the crash due to 
high volume of sip traffic in RSPAN vlan.
If you want I could collect pcap over a few seconds when opensips crashes, but 
it'll definitely have multiple packets and I'm not sure how to isolate the one 
that caused the crash. Anyway it's easily reproducible and crashes almost 
instantaneously, so I guess if you start raw capture on a vlan interface with 
some sip traffic you'll see it right away.
Thanks,

Michael

On Thursday, June 14, 2018 12:34:02 PM you wrote:
> Hi Michael,
> 
> Thanks for the information.
> 
> The printing msg shows that the src and dst IPs are correct.
> 
> Maybe a better approach will be to for me to try to reproduce this crash 
> - is it possible for you to reduce to a cfg file and a HEP packet that 
> produces the crash, so I can troubleshoot it ?
> 
> Thanks and regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>http://www.opensips.org/events/Summit-2018Amsterdam
> 
> On 06/05/2018 05:59 PM, Michael Ulitskiy wrote:
> > Hello,
> >
> > Here's msg->rcv:
> >
> > (gdb) frame 0
> > #0  0xb50bfb61 in w_sip_capture (msg=0xb738a810, table_name= > out>, resume_f=0x0, resume_param=0x0)
> >  at sipcapture.c:3433
> > 3433sco.msg.s = h->u.hepv12.payload;
> > (gdb) p msg->rcv
> > $2 = {src_ip = {af = 2, len = 4, u = {addrl = {2389972783, 3040358736, 
> > 3037670688, 3037552928}, addr32 = {
> >  2389972783, 3040358736, 3037670688, 3037552928}, addr16 = {5935, 
> > 36468, 12624, 46392, 11552, 46351,
> >  24864, 46349}, addr = "/\027t\216P18µ -\017µ a\rµ"}}, dst_ip = {af 
> > = 2, len = 4, u = {addrl = {
> >  1246982722, 3037552928, 31, 3077604236}, addr32 = {1246982722, 
> > 3037552928, 31, 3077604236}, addr16 = {
> >  29250, 19027, 24864, 46349, 31, 0, 33676, 46960}, addr = "BrSJ 
> > a\rµ\037\000\000\000\214\203p·"}},
> >src_port = 4940, dst_port = 5060, proto = 1, proto_reserved1 = 
> > -1257415776, proto_reserved2 = -1257467391,
> >src_su = {s = {sa_family = 2, sa_data = 
> > "\023L/\027t\216\000\000\000\000\000\000\000"}, sin = {sin_family = 2,
> >sin_port = 19475, sin_addr = {s_addr = 2389972783}, sin_zero = 
> > "\000\000\000\000\000\000\000"}, sin6 = {
> >sin6_family = 2, sin6_port = 19475, sin6_flowinfo = 2389972783, 
> > sin6_addr = {__in6_u = {
> >__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 
> > 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0,
> >  0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x807b872 
> > }
> >
> > If I set "hep_capture_on" set to 1 then it doesn't crash, but it doesn't 
> > store anything into db either.
> > Here's what it says:
> >
> > Jun  5 10:54:57 [3231] DBG:core:receive_msg: After parse_msg...
> > Jun  5 10:54:57 [3231] DBG:core:receive_msg: preparing to run routing 
> > scripts...
> > Jun  5 10:54:57 [3231] WARNING:sipcapture:w_sip_capture: not a hep message!
> > Jun  5 10:54:57 [3231] DBG:core:destroy_avp_list: destroying list (nil)
> > Jun  5 10:54:57 [3231] DBG:core:receive_msg: cleaning up
> >
> > Am I doing something wrong?
> > Thanks,
> >
> > Michael
> >
> > On Tuesday, June 05, 2018 01:39:03 PM Bogdan-Andrei Iancu wrote:
> >> Hi Michael,
> >>
> >> This crash seems to be triggered mainly by the "hep_capture_on" set to 0 .
> >>
> >> Just to check couple of things, using gdb, in frame 0, could you print
> >> msg->rcv ? it is interesting why those IPs are not valid (see the
> >> critical logs before the crash). Afterwards, the crash itself happened
> >> because

[OpenSIPS-Users] mid_registrar remove all bindings

2018-06-18 Thread vasilevalex

Hello.

We have simple schema Phone -> OpenSIPS with mid_registrar -> Asterisk. And
there is strange process for REGISTER message from Phone with "*" in Contact
(remove all bindings).

After standard sequence with Authorization and receiving Ok from Asterisk,
mid_registar generates additional REGISTER message with sequence number of
first (Unauthorized register) message. Asterisk of course answers with
error. This message contains Contact:
;expires=0. But is it needed, if we already
removed all bindings, and got the answer, that they are removed?


 


Phone 10.10.10.138 (external ip)
OpenSIPS 10.20.20.248
Asterisk 10.30.30.49

SIP Trace:

2018/06/18 12:48:50.165993 10.10.10.138:46583 -> 10.20.20.248:5060
REGISTER sip:siptest.test.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.141:46583;branch=z9hG4bK-iqcvselns7gw;rport
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" 
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2923 REGISTER
Max-Forwards: 70
User-Agent: snom725/8.7.5.35
Contact: *
Allow-Events: dialog
X-Real-IP: 172.16.1.141
Supported: path, gruu
Expires: 0
Content-Length: 0



2018/06/18 12:48:50.166602 10.20.20.248:5060 -> 10.30.30.49:5060
REGISTER sip:10.30.30.49 SIP/2.0
Via: SIP/2.0/UDP 10.20.20.248:5060;branch=z9hG4bK0cb5.808b8e8.0
Via: SIP/2.0/UDP
172.16.1.141:46583;received=10.10.10.138;branch=z9hG4bK-iqcvselns7gw;rport=46583
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" 
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2923 REGISTER
Max-Forwards: 69
User-Agent: snom725/8.7.5.35
Contact: *
Allow-Events: dialog
X-Real-IP: 172.16.1.141
Supported: path, gruu
Expires: 0
Content-Length: 0



2018/06/18 12:48:50.167363 10.30.30.49:5060 -> 10.20.20.248:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
10.20.20.248:5060;branch=z9hG4bK0cb5.808b8e8.0;received=10.20.20.248;rport=5060
Via: SIP/2.0/UDP
172.16.1.141:46583;received=10.10.10.138;branch=z9hG4bK-iqcvselns7gw;rport=46583
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" ;tag=as21b74178
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2923 REGISTER
Server: asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="56721c8c"
Content-Length: 0



2018/06/18 12:48:50.167614 10.20.20.248:5060 -> 10.10.10.138:46583
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
172.16.1.141:46583;received=10.10.10.138;branch=z9hG4bK-iqcvselns7gw;rport=46583
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" ;tag=as21b74178
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2923 REGISTER
Server: asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="56721c8c"
Content-Length: 0



2018/06/18 12:48:50.195562 10.10.10.138:46583 -> 10.20.20.248:5060
REGISTER sip:siptest.test.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.141:46583;branch=z9hG4bK-urxrbzyhmha1;rport
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" 
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2924 REGISTER
Max-Forwards: 70
User-Agent: snom725/8.7.5.35
Contact: *
Allow-Events: dialog
X-Real-IP: 172.16.1.141
Supported: path, gruu
Authorization: Digest
username="2552",realm="asterisk",nonce="56721c8c",uri="sip:siptest.test.com",response="093865994e1d93a398dfca21ae06f9cb",algorithm=MD5
Expires: 0
Content-Length: 0



2018/06/18 12:48:50.196083 10.20.20.248:5060 -> 10.30.30.49:5060
REGISTER sip:10.30.30.49 SIP/2.0
Via: SIP/2.0/UDP 10.20.20.248:5060;branch=z9hG4bKdbb5.def5a6b1.0
Via: SIP/2.0/UDP
172.16.1.141:46583;received=10.10.10.138;branch=z9hG4bK-urxrbzyhmha1;rport=46583
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" 
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2924 REGISTER
Max-Forwards: 69
User-Agent: snom725/8.7.5.35
Contact: *
Allow-Events: dialog
X-Real-IP: 172.16.1.141
Supported: path, gruu
Authorization: Digest
username="2552",realm="asterisk",nonce="56721c8c",uri="sip:siptest.test.com",response="093865994e1d93a398dfca21ae06f9cb",algorithm=MD5
Expires: 0
Content-Length: 0



2018/06/18 12:48:50.197335 10.30.30.49:5060 -> 10.20.20.248:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
10.20.20.248:5060;branch=z9hG4bKdbb5.def5a6b1.0;received=10.20.20.248;rport=5060
Via: SIP/2.0/UDP
172.16.1.141:46583;received=10.10.10.138;branch=z9hG4bK-urxrbzyhmha1;rport=46583
From: "Aleksei Vasilev" ;tag=y72nni51cm
To: "Aleksei Vasilev" ;tag=as21b74178
Call-ID: 313532383539333131363438303132-6ep4fjxmjp16
CSeq: 2924 REGISTER
Server: asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 0
Date: Mon, 18 Jun 2018 12:48:50 GMT
Content-Length: 0


This one is strange:

2018/06/18

[OpenSIPS-Users] Intermittent TLS Problem -

2018-06-18 Thread Callum Guy

Hi All,

I'm running a TLS protected service using OpenSIPs 2.3.3
and openssl-1.0.2k-12.el7.x86_64 on a CentOS 7.5 server. RTPProxy is in
place to forward all the media on every call.

OpenSIPs is acting as a proxy to an internal FreeSWITCH instance and
handling all inbound and outbound TLS negotiation.

The call scenario is:
Leg A: carrier -> opensips -> freeswitch (answer)
Leg B: freeswitch -> opensips ->carrier

I have a situation where calls sometimes fail during TLS negotiation on the
B leg. The exact same call will work only seconds before and then the
subsequent call will fail. This is still a test service so there is no
traffic on the platform which would effect the calls.

The destination carrier is Twilio where we are targeting a custom domain
which provides three separate fallback IP's. The logs (below) show each
being attempted in sequence and OpenSIPs is reporting failure.

I have a packet capture (SIP encrypted) which shows that the carrier
(Twilio) are setting up the connection and attempting to change the cipher
spec, from my understanding it looks like this is what triggers the errors
in OpenSIPs which then returns a SIP packet to Twilio before trying the
next IP in the list (see screen shot below).

When viewing the packet capture on a call which was not affected I don't
see wireshark reporting "Change Cipher Spec" from the carrier network so at
present this is the main suspicion. Unfortunately this is as far as my
current understanding can take me so while i continue to research i wanted
to reach out to see is anyone in the community can help! Let me know if I
can provide any further information.

Thanks!

*OpenSIPs Log*

Jun 18 11:20:33 opensips[6373]: INFO: [INVITE] (outbound) REST response:
RU: sip:+35361234567
<+353%2061%20234%20567>@custom.pstn.ie1.twilio.com:5061;transport=tls
DU: sip:custom.pstn.ie1.twilio.com:5061 FU: "+4940261234567
<+49%2040%20261234567>" 
To(sip:35361234567@172.18.0.110:5061;transport=tls)
From(sip:+40261234567@172.20.0.101) ID:137a5be9-ed84-1236-10aa-d0431e9b59cf
Jun 18 11:20:33 opensips[6373]: INFO:core:probe_max_sock_buff: using snd
buffer of 416 kb
Jun 18 11:20:33 opensips[6373]: INFO:core:init_sock_keepalive: TCP
keepalive enabled on socket 29
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 2
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 1
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 0
Jun 18 11:20:33 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
*Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:tls_blocking_write: TLS
send timeout (60)*
*Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:proto_tls_send: failed to
send*
*Jun 18 11:20:34 opensips[6373]: ERROR:tm:msg_send: send()
to 54.171.127.194:5061  for proto tls/3 failed*
*Jun 18 11:20:34 opensips[6373]: ERROR:tm:t_forward_nonack: sending request
failed*
Jun 18 11:20:34 opensips[6373]: INFO:core:probe_max_sock_buff: using snd
buffer of 416 kb
Jun 18 11:20:34 opensips[6373]: INFO:core:init_sock_keepalive: TCP
keepalive enabled on socket 29
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 2
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 0
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
*Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:tls_blocking_write: TLS
send timeout (60)*
*Jun 18 11:20:34 opensips[6373]: ERROR:proto_tls:proto_tls_send: failed to
send*
*Jun 18 11:20:34 opensips[6373]: ERROR:tm:msg_send: send()
to 54.171.127.193:5061  for proto tls/3 failed*
*Jun 18 11:20:34 opensips[6373]: ERROR:tm:t_forward_nonack: sending request
failed*
Jun 18 11:20:34 opensips[6373]: INFO:core:probe_max_sock_buff: using snd
buffer of 416 kb
Jun 18 11:20:34 opensips[6373]: INFO:core:init_sock_keepalive: TCP
keepalive enabled on socket 29
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 2
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: depth = 0
Jun 18 11:20:34 opensips[6373]: NOTICE:tls_mgm:verify_callback: preverify
is good: verify return: 1
*Jun 18 11:20:34 opensips[6373]:

Re: [OpenSIPS-Users] mid_registrar remove all bindings

[OpenSIPS-Users] sst module : update method instead of invite

Re: [OpenSIPS-Users] Intermittent TLS Problem -

Re: [OpenSIPS-Users] sipcapture segfaults when capturing on raw interface in all 2.x versions of opensips

[OpenSIPS-Users] mid_registrar remove all bindings

[OpenSIPS-Users] Intermittent TLS Problem -

6 matches

Site Navigation

Mail list logo

Footer information