[OpenSIPS-Users] mid_registrar feature request

[Giovanni Maruzzelli]

Hello!

I believe could be useful an MI command to resend all registrations to
backend.

Eg: mid-registar is working, demultiplying the registrations, passing them
back to a FreeSWITCH (or another OpenSIPS).

 They have no common database (eg: mid-registrar has its own DB, FS has itw
own separate DB). FS crashes, its own DB is deleted, FS restarts.

There is a need for something to force mid-registrar to resend all
registrations to FS...

-- 

Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Modified SDP from RTPEngine

[Pat Burke]

Hello, 




I am trying to get the IP address of the RTPEngine selected by the 
rtpengine_offer (we are load balancing across several rtpengines).  In 
rtpproxy, there was the optional parameter 

sock_pvar(optional) - pvar used to store the RTPProxy socket chosen for this 
call. Note that the variable will only be populated in the initial request.




There is no equivalent in rtpengine.  The following code, gets reads the 
request sdp line, but not the modified sdp.  Is there a way to get to the 
modified sdp?




                   rtpengine_offer("$dlg_val(rtpofferoptions)");

                    $var(regex) = "/c=IN IP4 //g";

                    $var(cline) = $(rb{sdp.line,c,0});

                    $var(ipaddr) = $(var(cline){re.subst,$var(regex)});

                    xlog("L_INFO", "$tU SCRIPT:RTPPROXY:DEBUG: response = 
$var(response) - $var(ipaddr) - $rc\n");

  



Regards,
Pat Burke



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

Re: [OpenSIPS-Users] mid-registrar and WSS

[Esty, Ryan]

All,

Never mind it is registering now. I still have some work to do but after more 
investigation the SIP server was deleting the second VIA which was the via for 
WSS. Now on the register I save it to an avp and then in my register's 
onreply_route I just do an append_hf("Via: ..."). The client sipml5 registers 
and now I can try making calls.

Ryan



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

Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects

[Carlos Oliva]

Hi!

Many thanks Bodgan and Dan for the analysis.

I made some attack tests in our MediaProxy installation and this
impersonation is possible, but very difficult to success. You must be
quicker than the legitimate user sending RTP to the right ports. Other
relays are continuously learning the media destination from the last
received packet, it not seems to be the case of MediaProxy. I think is not
needed to be in the signalling path, you can spray the port range of media
relay with packets randomly because send UDP packets is very cheap. I used
rtpnatscan utility (with few modifications) to do the tests.

I think RTP with NAT involved can not be authenticated in any way, is a
problem of the protocol itself and we can do nothing about that. I agree
with Dan the only thing we can do for privacy is to use SRTP or ZRTP where
possible.

I only found a possible improvement to MediaProxy. It allocates ports in
consecutive and very predictable way and maybe a future improvement could
be to randomize the selected ports to mitigate the possibility of a
successful attack. Just my 2 cents.

very grateful for your response,

Carlos Oliva




2018-03-13 11:20 GMT+01:00 Dan Pascu :

> I find the information on that site to be confusing because they lump
> multiple distinct problems under the same name as if they are a single
> issue. They also have some mistakes in their assertions.
>
> So rather than address it from the point of view expressed on the site,
> let me explain what the possible problems are.
>
> Mediaproxy 2 doesn't suffer from eavesdropping issues itself, because it
> learns the addresses of the participants and it will only forward traffic
> between those addresses, not to any listening 3rd party. However
> eavesdropping is a general issue for unencrypted RTP streams because any
> ISP in the path of those packets can listen to them without leaving any
> trace, no matter what relaying solution you use or if you use a relay at
> all.
>
> Mediaproxy 2 can be affected by impersonation. Because the relay learns
> the addresses of the endpoints from the first RTP packets, if an attacker
> would send RTP first, it would take the place of one of the participants in
> the call and all further RTP traffic will be forwarded to this attacker
> instead of the original participant. This allows the attacker to pretend to
> be the person he tries to impersonate. However unlike the site you
> mentioned claims, the attacker needs to have a privileged position within
> the network to do so. In order for this kind of attack to succeed, the
> attacker needs to be in the SIP signaling path, in order to be able to see
> the SIP traffic and learn the RTP IP/port where to send his packets. The
> ports allocated by mediaproxy cannot be guessed otherwise. In addition to
> having this privileged position in the network, the attacker also need to
> be closer to the media relay than the participant he tries to impersonate,
> so his RTP traffic reaches the relay first and mediaproxy learns the
> attacker's address before the original participant's traffic has a chance
> to arrive at the relay.
>
> In short impersonation can happen if the attacker can see the SIP traffic
> and learn the media IP/port and is closer to the relay to send its RTP
> first.
>
> To prevent this you should use TLS for SIP signaling. But keep in mind
> that your SIP service provider and any other SIP service provider involved
> in the calls you make need to use TLS, as well as the other endpoint of the
> call needs to use TLS. Otherwise some SIP traffic will be sent in clear.
>
> To prevent eavesdropping you should use encrypted media, but keep in mind
> that if you use SRTP, unless you use TLS end to end for SIP, the encryption
> keys will be leaked in the SIP signaling.
>
> The best solution you have for both eavesdropping and impersonation is to
> use zRTP for media encryption. Not only it will prevent eavesdropping by
> encrypting the media, but it will also authenticate the other user
> preventing impersonation. If an attacker succeeds in impersonating a RTP
> endpoint you will know that you are not talking to who you expect to be
> talking. In addition zRTP negotiates the encryption in real time, so it
> doesn't suffer from the same problem SRTP suffers with leaked keys, so it
> works even if you do not use TLS for SIP signaling.
>
> Hope this clarifies the subject a bit.
>
> On 12 Mar 2018, at 12:58, Carlos Oliva wrote:
>
> > Hi List:
> >
> > I have some questions about mediaproxy 2 ad rtpbleed vulnerability
> https://www.rtpbleed.com/
> >
> > Is MediaProxy 2  vulnerable to this attack?
> >
> > If so, the media can be hijacked only at very begining or throughout the
> entire call?
> >
> > If an attacker hijacks the media the other party will stop hears the
> call or the RTP will be send to both ends?
> >
> >
> > Thanks for your help!
> >
> > thanks and Regards,
> >
> > Carlos Oliva
> > ___

Re: [OpenSIPS-Users] Problem with simultaneous CANCEL + 200 OK

[Daniel Zanutti]

Hi Bogdan

I could reproduce the problem on lab. This is the scenario:

A INVITE -> OPENSIPS
OPENSIPS INVITE -> B

OPENSIPS <- B 200 OK

A <- 200 OK OPENSIPS
This 200 OK is lost or discarded on A, not sure if was on network or
problem at client. Then:

A CANCEL -> OPENSIPS
A <- 200 OK (of Cancel) OPENSIPS

Then the call is up for ever.

Here is the log at the moment the CANCEL is received:
https://pastebin.com/79qanD2H

And PCAP:
https://drive.google.com/file/d/1lpHWN1uRD1SOwBTZdijSodXBWhUX-rM8/view?usp=sharing

Can you help?

Thanks





On Thu, Feb 22, 2018 at 1:24 PM, Bogdan-Andrei Iancu 
wrote:

> Daniel,
>
> The pcap shows only one leg of the the communication (I guess caller
> versus OpenSIPS). So I cannot see what happens on the callee side. Still, I
> see the first cancel is rejected with 400 (I guess by OpenSIPS - check the
> logs to see the reason) and the second one is accepted by OpenSIPS (no idea
> if relayed to callee or not). Still, if there is a race between the cancel
> from caller and the answer from callee, it is up to the caller to sort it
> outaccording to RFC, the caller must ACK the received 200 OK (even if
> CANCEL was sent) and if it really wants to terminate the call, it has to
> fire a BYE.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> On 02/22/2018 04:22 PM, Daniel Zanutti wrote:
>
> Hi Bogdan
>
> Thanks for replying.
>
> Here is the PCAP, please take a look: https://drive.google.
> com/file/d/1e7SKjxDtdVYmN-7fCHSEqNEsNHjPsaKo/view?usp=sharing
>
> Thanks
>
> On Thu, Feb 22, 2018 at 7:30 AM, Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Daniel,
>>
>> Without a pcap showing the signaling is hard to understand (not to
>> mention helping) your scenario. Please provide a link to the pcap or ngrep.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Summit 2018
>>   http://www.opensips.org/events/Summit-2018Amsterdam
>>
>> On 02/20/2018 06:43 PM, Daniel Zanutti wrote:
>>
>> Hey
>>
>> I had a problem when receiving simultaneous CANCEL from customer and 200
>> OK from gateway.
>>
>> Seems that the first CANCEL was rejected, but the second CANCEL was
>> accepted. This second CANCEL did NOT go to the gateway, just Opensips
>> received and replied with 200 OK.
>>
>> This is the log of the first CANCEL:
>> Feb 15 18:39:22 /sbin/opensips[28845]: SCRIPT:TRAFFIC:WARNING: method
>> CANCEL ( 7Qbq3O3CReMfPflAtl8NY3ddTqPVBHO2785126@2.2.2.2/ XAeG2xj278512T2
>> / 1839212581509953 ) not validated and not fixed ( code=-1 )
>>
>> code -1 is the return of validate_dialog()
>>
>> Second CANCEL didn't generated a log.
>>
>> Shouldn't all CANCELs be rejected? On this case, just the first one was
>> rejected.
>>
>> I'm using version 1.9.11.
>>
>>
>>
>>
>> ___
>> 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

Re: [OpenSIPS-Users] WebRTC Socket problem 2.3 mid registrar

[Sebastian Sastre]

Liviu,

I used git to clone the repot . Im assuming is the latest ?


*git clone https://github.com/OpenSIPS/opensips.git
 -b 2.3 opensips-2.3*


On Wed, Mar 14, 2018 at 5:06 AM, Liviu Chircu  wrote:

> Hi Sebastian,
>
> Are you using the major (initial) release RPM of 2.3, or the latest minor
> release one? This issue has only been fixed a couple of months ago -- the
> fix is available starting with 2.3.3.
>
> Regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 13.03.2018 21:19, Sebastian Sastre wrote:
>
> Razvan,
>
> You are right, It actually looks like a bug with mid_registrar, I changed
> the function from midregistar_save to save only and I can now see the
> received attribute.
>
>
> *This is my registration Route *
> As you can see I call the fix_nated_register right before calling the save
>
>
>
>
>
> route {
> if (is_method("REGISTER")){
> route(user_registration);
> exit;
> }
> }
>
> route[user_registration]{
>
> xlog("L_INFO","$var(prefix) - [Registration Route]  \n");
> if (!www_authorize("", "subscriber")){
> xlog("L_INFO","$var(prefix) -  Challenge, come back with good
> credentials  \n");
> www_challenge("", "1");
> exit;
> }
>
> setflag(TCP_PERSIST_REGISTER);
> setflag(TCP_PERSIST_REGISTRATIONS);
> setbflag(NAT_BFLAG);
>
> if (!db_check_to()){
> xlog("L_INFO","$var(prefix) -  Forbidden auth ID  \n");
> sl_send_reply("403","Forbidden auth ID");
> exit;
> }
>
> fix_nated_register();
> mid_registrar_save("location", "mf", "$fu");
> switch ($retcode) {
> case 1:
> xlog("L_INFO","$var(prefix) -  Registration Successfull
> (Forwarding) \n");
> $ru = "sip:10.101.10.153:5060";
> t_relay();
> break;
> case 2:
> xlog("L_INFO","$var(prefix) -  Registration Successfull
> (absorbing) \n");
> break;
> default:
> xlog("L_INFO","$var(prefix) -  failed to save registration!
> ($$ci=$ci)\n");
> sl_reply_error();
> exit;
> }
>
> exit;
> }
>
> On Tue, Mar 13, 2018 at 11:43 AM, Răzvan Crainea 
> wrote:
>
>> Hi, Sebastian!
>>
>> The fix_nated_register() doesn't seem to be called for REGISTERs, because
>> I don't see any "Received" line in the "ul dump" command. Make sure you
>> call fix_nated_register() for all the WSS REGISTER messages.
>>
>> Best regards,
>> Răzvan
>>
>> On 03/12/2018 10:28 PM, Sebastian Sastre wrote:
>>
>>>
>>> I’m experiencing a problem regarding web socket registrations. I saw a
>>> similar thread but didn’t have a resolution so here we go.
>>>
>>> Im using the 2.3 Branch with rtpengine , wss and mid registrar. Using
>>> Sip.js library I can register the client without a problem and also able to
>>> place calls thru an asterisk box without problems. To be exact, my setup is
>>>
>>> Sip.JS ——> Opensips + rtpengine —-> Asterisk 1.3 —-> PSTN
>>>
>>>
>>> However, when trying to call the subscriber from asterisk (opposite
>>> direction), opensips fails to get a valid tcp connection. It complagreatins
>>> about not finding a suitable tcp and timing out to a TCP block 477/TM
>>> transaction.
>>>
>>> DBG:proto_wss:proto_wss_send: no open tcp connection found, opening new
>>> one
>>> DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384
>>> DBG:core:probe_max_sock_buff: trying : 32768
>>> DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536
>>> DBG:core:probe_max_sock_buff: trying : 65536
>>> DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072
>>> DBG:core:probe_max_sock_buff: trying : 131072
>>> DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262144
>>> DBG:core:probe_max_sock_buff: trying : 262144
>>> DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=425984
>>> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
>>> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 7
>>> ERROR:core:tcp_connect_blocking: timeout 99198 ms elapsed from 10 s
>>> ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed
>>> ERROR:proto_wss:ws_connect: connect failed
>>> ERROR:proto_wss:proto_wss_send: connect failed
>>> ERROR:tm:msg_send: send() to 192.0.2.48:443  for
>>> proto wss/6 failed
>>> ERROR:tm:t_forward_nonack: sending request failed
>>>
>>> Whats interesting is that if I execute a constant opensipsctl fifo
>>> list_tcp_conns, The connection never drops.
>>>
>>> *root@gcwRegistrar151:~$ opensipsctl fifo list_tcp_conns*
>>> Connection::  ID=1189087375 Type=wss State=0 Source=192.168.91.2:60888 <
>>> http://192.168.91.2:60888> Destination=10.101.10.151:443 <
>>> http://10.101.10.151:443> Lifetime=2106-02-07 02:28:25
>>>
>>>
>>> I tried seting the tcp_persistent_flag before the register and the NAT
>>> flag as well. Here is the AOR
>>>
>>> *This is the registration part. *
>>> *
>>> *
>>>
>>> setflag(TCP_PERSIST_REGISTRATIONS);
>>> fix_nated_register();
>>> 

[OpenSIPS-Users] mid-registrar and WSS

[Esty, Ryan]

Hi opensips users,

I have a couple of questions and I'm hoping someone can point me in the right 
direction.

We have a SIP PBX that doesn't do WSS for example using sipml5. I'm trying to 
put opensips in the middle of the SIP PBX and the WSS client with limited 
success using mid-registrar in opensips 2.3. If I don't try to pass the 
registration through and just use opensips as my SIP server the WSS client will 
register and calls can be made. If I do put in the mid-registrar and pass 
through the registration to the SIP PBX the SIP PBX will register the phone and 
pass back the 200 OK the client gets a message back but doesn't think it is for 
him because I'm assuming it is missing the VIA. On a successful registration 
the client will see the VIA on the unsuccessful registration the client doesn't 
see the VIA.


My first question is am I using the mid-registrar as designed I'm trying to set 
it up as contact mirroring (mode 0)? If I did pick the correct method why is my 
VIA disappearing and can I get it back? Someone on the list mentioned this 
https://blog.opensips.org/2016/12/13/how-to-proxy-sip-registrations and I will 
try it soon but it seemed the mid-registrar which I don't think was released 
yet was supposed to automatically do this.

This is the debug output when the registration is failed:
SEND: REGISTER sip:192.168.40.175 SIP/2.0
Via: SIP/2.0/WSS 
df7jal23ls0d.invalid;branch=z9hG4bKd7RGgr1eBtcOk2yUuIUuyvIqWk3G3Or0;rport
From: "Skwisgaar Skwigelf";tag=T9XcAa1Am5fIDrtIo68Z
To: "Skwisgaar Skwigelf"
Contact: "Skwisgaar 
Skwigelf";expires=200;click2call=no;+g.oma.sip-im;+audio;language="en,fr"
Call-ID: 766574bd-8060-562d-1f67-24975848739c
CSeq: 5334 REGISTER
Content-Length: 0
Route: 
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
Organization: Doubango Telecom
Supported: path


SIPml-api.js?svn=252:1 ==session event = connecting
SIPml-api.js?svn=252:1 ==session event = sent_request
SIPml-api.js?svn=252:1 __tsip_transport_ws_onmessage
SIPml-api.js?svn=252:1 recv=SIP/2.0 200 OK
From: "Skwisgaar Skwigelf";tag=T9XcAa1Am5fIDrtIo68Z
To: "Skwisgaar 
Skwigelf";tag=83a00482-48f7-4f78-ab314b6aacadc545
Contact: 
;expires=200
Call-ID: 766574bd-8060-562d-1f67-24975848739c
CSeq: 5334 REGISTER
Content-Length: 0
Server: Sphericall/9.1.0 Build/669
Allow: 
INVITE,ACK,CANCEL,OPTIONS,REFER,BYE,REGISTER,SUBSCRIBE,NOTIFY,UPDATE,PRACK,MESSAGE,INFO
Allow-Events: message-summary,presence

This is the debug output when the registration is successful:
SEND: REGISTER sip:192.168.40.175 SIP/2.0
Via: SIP/2.0/WSS 
df7jal23ls0d.invalid;branch=z9hG4bKLpgkzXTPZl5D5ghXuZ1vmNZXUn9nHkMr;rport
From: "Skwisgaar Skwigelf";tag=RyaJ7SLKEeeTS8r9v0BX
To: "Skwisgaar Skwigelf"
Contact: "Skwisgaar 
Skwigelf";expires=200;click2call=no;+g.oma.sip-im;+audio;language="en,fr"
Call-ID: 6e7fe61e-a51f-96cf-a9a0-e3c3785259b9
CSeq: 7252 REGISTER
Content-Length: 0
Route: 
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
Organization: Doubango Telecom
Supported: path


SIPml-api.js?svn=252:1 ==session event = connecting
SIPml-api.js?svn=252:1 __tsip_transport_ws_onmessage
SIPml-api.js?svn=252:1 recv=SIP/2.0 200 OK
Via: SIP/2.0/WSS 
df7jal23ls0d.invalid;rport=60161;received=172.25.111.53;branch=z9hG4bKLpgkzXTPZl5D5ghXuZ1vmNZXUn9nHkMr
From: "Skwisgaar Skwigelf";tag=RyaJ7SLKEeeTS8r9v0BX
To: "Skwisgaar 
Skwigelf";tag=54638b9941aeeb05912f3f3563e30b77.7a8c
Contact: 
;expires=200;received="sip:172.25.111.53:60161;transport=WSS"
Call-ID: 6e7fe61e-a51f-96cf-a9a0-e3c3785259b9
CSeq: 7252 REGISTER
Content-Length: 0
Server: OpenSIPS (2.3.3 (x86_64/linux))

Ryan

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

Re: [OpenSIPS-Users] WebRTC Socket problem 2.3 mid registrar

[Liviu Chircu]

Hi Sebastian,

Are you using the major (initial) release RPM of 2.3, or the latest 
minor release one? This issue has only been fixed a couple of months ago 
-- the fix is available starting with 2.3.3.


Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 13.03.2018 21:19, Sebastian Sastre wrote:

Razvan,

You are right, It actually looks like a bug with mid_registrar, I 
changed the function from midregistar_save to save only and I can now 
see the received attribute.



*This is my registration Route *
As you can see I call the fix_nated_register right before calling the 
save






route {
if (is_method("REGISTER")){
route(user_registration);
exit;
}
}

route[user_registration]{

xlog("L_INFO","$var(prefix) - [Registration Route]  \n");
if (!www_authorize("", "subscriber")){
    xlog("L_INFO","$var(prefix) -  Challenge, come back with good 
credentials  \n");

    www_challenge("", "1");
    exit;
}
    setflag(TCP_PERSIST_REGISTER);
setflag(TCP_PERSIST_REGISTRATIONS);
    setbflag(NAT_BFLAG);

if (!db_check_to()){
xlog("L_INFO","$var(prefix) -  Forbidden auth ID  \n");
sl_send_reply("403","Forbidden auth ID");
exit;
}
    fix_nated_register();
    mid_registrar_save("location", "mf", "$fu");
    switch ($retcode) {
    case 1:
        xlog("L_INFO","$var(prefix) -  Registration Successfull 
(Forwarding) \n");

        $ru = "sip:10.101.10.153:5060 ";
        t_relay();
        break;
    case 2:
        xlog("L_INFO","$var(prefix) -  Registration Successfull 
(absorbing) \n");

        break;
    default:
        xlog("L_INFO","$var(prefix) -  failed to save registration! 
($$ci=$ci)\n");

        sl_reply_error();
        exit;
    }

exit;
}

On Tue, Mar 13, 2018 at 11:43 AM, Răzvan Crainea > wrote:


Hi, Sebastian!

The fix_nated_register() doesn't seem to be called for REGISTERs,
because I don't see any "Received" line in the "ul dump" command.
Make sure you call fix_nated_register() for all the WSS REGISTER
messages.

Best regards,
Răzvan

On 03/12/2018 10:28 PM, Sebastian Sastre wrote:


I’m experiencing a problem regarding web socket registrations.
I saw a similar thread but didn’t have a resolution so here we go.

Im using the 2.3 Branch with rtpengine , wss and mid
registrar. Using Sip.js library I can register the client
without a problem and also able to place calls thru an
asterisk box without problems. To be exact, my setup is

Sip.JS ——> Opensips + rtpengine —-> Asterisk 1.3 —-> PSTN


However, when trying to call the subscriber from asterisk
(opposite direction), opensips fails to get a valid tcp
connection. It complagreatins about not finding a suitable tcp
and timing out to a TCP block 477/TM transaction.

DBG:proto_wss:proto_wss_send: no open tcp connection found,
opening new one
DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384
DBG:core:probe_max_sock_buff: trying : 32768
DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536
DBG:core:probe_max_sock_buff: trying : 65536
DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072
DBG:core:probe_max_sock_buff: trying : 131072
DBG:core:probe_max_sock_buff: setting snd:
set=131072,verify=262144
DBG:core:probe_max_sock_buff: trying : 262144
DBG:core:probe_max_sock_buff: setting snd:
set=262144,verify=425984
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 7
ERROR:core:tcp_connect_blocking: timeout 99198 ms elapsed from
10 s
ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed
ERROR:proto_wss:ws_connect: connect failed
ERROR:proto_wss:proto_wss_send: connect failed
ERROR:tm:msg_send: send() to 192.0.2.48:443
  for proto
wss/6 failed
ERROR:tm:t_forward_nonack: sending request failed

Whats interesting is that if I execute a constant opensipsctl
fifo list_tcp_conns, The connection never drops.

*root@gcwRegistrar151:~$ opensipsctl fifo list_tcp_conns*
Connection::  ID=1189087375 Type=wss State=0
Source=192.168.91.2:60888 
 Destination=10.101.10.151:443
 
Lifetime=2106-02-07 02:28:25


I tried seting the tcp_persistent_flag before the register and
the NAT flag as well. Here is the AOR

*This is the registration part. *
*
*

setflag(TCP_PERSIST_REGISTRATIONS);
fix_nated_register();
setbflag(NAT_BFLAG);

if (!db_check_to()){