[OpenSIPS-Users] WebRTC Socket problem 2.3 mid registrar

Sebastian Sastre sastre.sebastian at gmail.com
Wed Mar 14 10:34:46 EDT 2018


Liviu,

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


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


On Wed, Mar 14, 2018 at 5:06 AM, Liviu Chircu <liviu at opensips.org> 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 <razvan at opensips.org>
> 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 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 <http://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 <
>>> 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();
>>> 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 <http://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 <mailto:agent at gcwregistrar.dom
>>> ain.com>*
>>>                  Contact:: sip:bcd9bu7j at 192.0.2.37 <mailto:
>>> sip%3Abcd9bu7j 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 <
>>> http://10.101.10.151:443>
>>>                          Methods:: 5439
>>>                          SIP_instance:: <urn:uuid:07e6eb5c-2294-42a1-b
>>> 263-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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> --
>> Răzvan Crainea
>> OpenSIPS Core Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Summit 2018
>>   http://www.opensips.org/events/Summit-2018Amsterdam
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180314/a935b9ef/attachment-0001.html>


More information about the Users mailing list