[OpenSIPS-Users] WebRTC Socket problem 2.3 mid registrar

[Sebastian Sastre]

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 100000 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 at 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()){
     xlog("L_INFO","$var(prefix) -  Forbidden auth ID  \n");
  sl_send_reply("403","Forbidden auth ID");
  exit;
}


mid_registrar_save("location", "mf");
    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;
    }


*And here is the lookup part.*

if (mid_registrar_lookup("location", "m")){
  xlog("L_INFO","$var(prefix) -  Call is for local user $rU , forwarding
... \n");
  route(inbound_call);
}

Domain:: location hash_size=512
     *   AOR:: agent at gcwregistrar.domain.com
<agent at gcwregistrar.domain.com>*
                Contact:: sip:bcd9bu7j at 192.0.2.37;transport=wss Q=
                        ContactID:: 1722063907515827933
                        Expires:: 352
                        Callid:: 4oqvt7es6ga8pqd8ei7nt0
                        Cseq:: 193
                        User-agent:: SIP.js/0.7.8 BB
                        State:: CS_NEW
                        Flags:: 0
                        Cflags:: NAT_BFLAG
                        Socket:: wss:10.101.10.151:443
                        Methods:: 5439
                        SIP_instance::
<urn:uuid:07e6eb5c-2294-42a1-b263-a00642b0c277>



I don’t think its related to the mid registrar since I tried just using the
regular registrar and the same thing happens.

Any ideas?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180312/ade6b8e3/attachment-0001.html>