[OpenSIPS-Users] rabbitMq_publish (async ?)

[Wadii ELMAJDI | Evenmedia]

Hello,

I am using the new rabbitmq module to send some informations as AMQP messages 
to a rabbitmq server. Mostly fraud detection + CDR.

I wanted to know if rabbitmq_publish is considered a blocking function? for 
example in the case of fraud detection warning, my use case is to publish the 
message to rabbitmq server and continue the sip routing decision without 
hanging up the call.

Should i use the launch statement , or is rabbitmq_publish not a blocking 
function already ?

Ex : launch(rabbitmq_publish(...));

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

[OpenSIPS-Users] Registrar module

[nutxase via Users]

Hi Guys

I notice when i enable the registrar module any registration attempt is getting 
a 200
How can i stop this and make authenticate them based on what i have in mysql?

Sent with [Proton Mail](https://proton.me/) secure email.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Liviu Chircu]

On 17.01.2023 19:01, Daren FERREIRA wrote:
Jan 17 17:26:16 opensips[2810991]: 
DBG:mid_registrar:build_unregister_hdrs: extra hdrs: 'Contact: 
;expires=0#015#012'
Jan 17 17:26:16 opensips[2810991]: DBG:tm:t_uac: 
next_hop=

Jan 17 17:26:16 opensips[2810991]: DBG:core:mk_proxy: doing DNS lookup...
Jan 17 17:26:16 opensips[2810991]: DBG:core:sip_resolvehost: no port, 
no proto -> do NAPTR lookup!


If I well understand, OpenSIPS tries to generate the de-register, and 
first, determine the destination of the de-register (from AOR ?)
It considers it knows not enough about the protocol and port to use to 
generate the de-register and try to fill these informations from DNS.
This logically fails because there is no SRV nor NAPTR records for the 
FQDN extracted (from AOR).


The mid-registrar will typically *store* the R-URI ($ru) + 
Destination-URI ($du) combination, after you t_relay() the REGISTER 
towards the main registrar.  This info will be used in order to route a 
De-REGISTER in the exact same way (same message R-URI, sent to the same 
box).


Apparently, you are routing the REGISTER without setting a *$du *(notice 
the *"adding next hop: ..."* debug log in send_unregister() 
, 
which is NOT printed), so the mid-registrar attempts to send the 
De-REGISTER to *sip:myhost.mydomain.com*, which was grabbed either from 
the R-URI (most likely) or To header of the initial REGISTER.  And, 
before sending the packet, of course it needs to resolve the hostname to 
an IP address.  If there are any issues during this resolution... you 
must let me know of any relevant logs, as I have no idea.


Hopefully, you have some pointers to look out for now.

Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Daren FERREIRA]

Great!

Thank you for your tips.
With the debug, I think I found the culprit:

Jan 17 17:26:16 opensips[2810991]: DBG:usrloc:run_ul_callbacks: 
contact=0x7f90c91662b0, callback type 128/208, id 1 entered
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:mid_reg_aor_event: AOR 
callback (128): contact=‘4...@myhost.mydomain.com'
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: 
building contact from uri 'sip:4413%40myhost.mydomain.com@192.168.10.11:5060'
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: 
extra hdrs: 'Contact: 
;expires=0#015#012'
Jan 17 17:26:16 opensips[2810991]: DBG:tm:t_uac: 
next_hop=
Jan 17 17:26:16 opensips[2810991]: DBG:core:mk_proxy: doing DNS lookup...
Jan 17 17:26:16 opensips[2810991]: DBG:core:sip_resolvehost: no port, no proto 
-> do NAPTR lookup!

If I well understand, OpenSIPS tries to generate the de-register, and first, 
determine the destination of the de-register (from AOR ?)
It considers it knows not enough about the protocol and port to use to generate 
the de-register and try to fill these informations from DNS.
This logically fails because there is no SRV nor NAPTR records for the FQDN 
extracted (from AOR).

On UL database we have:

  "AOR": "4...@myhost.mydomain.com",
  "Contacts": [
{
  "Contact": "sip:4413@10.124.112.93:8851;rinstance=B470D0A1",
  "ContactID": "4067622841722148511",
  "Expires": "expired",
  "Q": "",
  "Callid": "9838BED5A44A0EC828005D9103086185EB431CDB",
  "Cseq": 106,
  "User-agent": "Clientt/4.6 (build 1377598; Android 11; arm64-v8a)",
  "Received": "sip:37.166.229.129:54630",
  "State": "CS_SYNC",
  "Flags": 0,
  "Cflags": "NAT",
  "Socket": "udp:192.168.10.11:5060",
  "Methods": 5183
}
  ]

I didn’t find how to, either define the default port and protocol, or to add it 
to the UL database at mid_registrar_save.

Should I generate a custom AOR containing something like sip:$domain:5060 at 
every mid_registrar_save ?

Thank you very much for your help.

Best regards




> Le 17 janv. 2023 à 16:57, Liviu Chircu  a écrit :
> 
> On 17.01.2023 17:09, Daren FERREIRA wrote:
>> 
>> My understanding was opensips should do the cleaning, as mentioned on the 
>> documentation.
>> 
>> A common occurence is for some SIP User Agents to lose their network 
>> connection (especially when dealing with mobile devices), hence they do not 
>> properly de-register from the mid-registrar. In this case, in order to avoid 
>> stale registrations on the main registrar (which contains SIP contacts with 
>> greatly extended lifetimes!), the mid-registrar will appropriately generate 
>> De-REGISTER requests and remove these contacts from the main registrar's 
>> location service as soon as it considers them to have expired. 
>> 
>> Have I misunderstood?
>> If not, what can explain the un-register to never been sent by OpenSIPS?
>> 
> You understood it perfectly.  My suggestion would be to skim through the code 
> of mid_reg_aor_event() 
> 
>  internal callback (it's pretty straight-forward), to get an idea of the 
> DEBUG logging it can do, as well as "OK" code paths and "NOT OK" code paths.
> 
> Once you know what to look for, try to put OpenSIPS in debug mode 
> ("opensips-cli -x mi log_level 4") and follow with the DEBUG logs when the 
> AoR is deleted by the timer process.  Let's see what it prints!  Of course, 
> you should put it back to normal logging ASAP afterwards.
> 
> Best regards,
> 
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu  | 
> www.opensips-solutions.com 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Liviu Chircu]

On 17.01.2023 17:09, Daren FERREIRA wrote:


My understanding was opensips should do the cleaning, as mentioned on 
the documentation.


/A common occurence is for some SIP User Agents to lose their network 
connection (especially when dealing with mobile devices), hence they 
do not properly de-register from the mid-registrar. In this case, in 
order to avoid stale registrations on the main registrar (which 
contains SIP contacts with greatly extended lifetimes!), the 
mid-registrar will appropriately generate De-REGISTER requests and 
remove these contacts from the main registrar's location service as 
soon as it considers them to have expired. /


Have I misunderstood?
If not, what can explain the un-register to never been sent by OpenSIPS?

You understood it perfectly.  My suggestion would be to skim through the 
code of mid_reg_aor_event() 
 
internal callback (it's pretty straight-forward), to get an idea of the 
DEBUG logging it can do, as well as "OK" code paths and "NOT OK" code paths.


Once you know what to look for, try to put OpenSIPS in debug mode 
("opensips-cli -x mi log_level 4") and follow with the DEBUG logs when 
the AoR is deleted by the timer process.  Let's see what it prints!  Of 
course, you should put it back to normal logging ASAP afterwards.


Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu  |www.opensips-solutions.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Daren FERREIRA]

Hi Liviu,

Thank you for your reply.

I don’t expect an unregister from one device to trigger a de-register for the 
two, that would be illogic.
It would make sense only if the device is the last registered one. 

In our case, captures would be useless. That would only show no de-REGISTER is 
sent by OpenSIPS.

Please, let me try to best describe the case and my understanding.

We are in mode==2.
You have several devices registering (2).
The devices register with an expire < 3600 (in our case, around 600).
Opensips registers with a default_expires (3600 by default) (that’s expected, 
that’s a way to throttle and reduce backend load).

The devices are disconnected from internet, so their registry is not renewed, 
and expires (from client side view).
OpenSIPS doesn’t send any de-register even if all endpoints registry have 
expired.

My understanding was opensips should do the cleaning, as mentioned on the 
documentation.

A common occurence is for some SIP User Agents to lose their network connection 
(especially when dealing with mobile devices), hence they do not properly 
de-register from the mid-registrar. In this case, in order to avoid stale 
registrations on the main registrar (which contains SIP contacts with greatly 
extended lifetimes!), the mid-registrar will appropriately generate De-REGISTER 
requests and remove these contacts from the main registrar's location service 
as soon as it considers them to have expired. 

Have I misunderstood?
If not, what can explain the un-register to never been sent by OpenSIPS?


Thank you

Best regards


> Le 17 janv. 2023 à 15:13, Liviu Chircu  a écrit :
> 
> On 12.01.2023 17:26, Daren FERREIRA wrote:
>> If I well understood, if a client is registered with a 500 seconds expiry, 
>> the server side is set to outgoing_expires, and, if the register is not 
>> renewed by the client, opensips should de-register.
>> 
>> In my case, the de-registers that should be triggered are never triggered.
>> 
>> I found no parameters relative to this in mid_registrar module, but, looking 
>> at the source code, it seems it depends on usrloc module.
>> On usrloc module, it seems that contact_refresh_timer is in charge of 
>> treating events, like expires, so I tried to enable it, without success.
>> Even after client expiry + timer_interval, the client is not de-registered 
>> on server side.
>> 
>> Is there anything I may have missed?
> 
> Hi Daren,
> 
> I notice you are using "mode == 2", which means De-REGISTERs will only be 
> generated when the AoR gets deleted.  For example, if you have 2 SIP UAs 
> registering to the same AoR and you are trying to kill one of them in an 
> attempt to see a De-REGISTER being auto-generated downstream, that will never 
> happen!  This is because the remaining Contact is enough to maintain 
> "liveness" of the AoR to the downstream registrar.
> 
> Let me know if this is the case - if not, we can continue digging.  Ideally, 
> a SIP trace (.pcap or .txt) for the entire flow  would be helpful (you can 
> email it to me personally, if privacy is an issue).
> 
> Best regards,
> 
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
> 

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

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Liviu Chircu]

On 12.01.2023 17:26, Daren FERREIRA wrote:
If I well understood, if a client is registered with a 500 seconds 
expiry, the server side is set to outgoing_expires, and, if the 
register is not renewed by the client, opensips should de-register.


In my case, the de-registers that should be triggered are never triggered.

I found no parameters relative to this in mid_registrar module, but, 
looking at the source code, it seems it depends on usrloc module.
On usrloc module, it seems that contact_refresh_timer is in charge of 
treating events, like expires, so I tried to enable it, without success.
Even after client expiry + timer_interval, the client is not 
de-registered on server side.


Is there anything I may have missed?


Hi Daren,

I notice you are using "mode == 2", which means De-REGISTERs will only 
be generated when the AoR gets deleted.  For example, if you have 2 SIP 
UAs registering to the same AoR and you are trying to kill one of them 
in an attempt to see a De-REGISTER being auto-generated downstream, that 
will never happen!  This is because the remaining Contact is enough to 
maintain "liveness" of the AoR to the downstream registrar.


Let me know if this is the case - if not, we can continue digging.  
Ideally, a SIP trace (.pcap or .txt) for the entire flow  would be 
helpful (you can email it to me personally, if privacy is an issue).


Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com


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

[OpenSIPS-Users] How to process CANCEL in b2b anycast mode?

[Denys Pozniak]

Hello!

I'm trying to build a solution with anycast + b2b.
But I ran into a problem, if the dialogue is in an early state on node1,
and CANCEL arrives on node2, then this request itself is no longer
processed in the context of the b2b (does not jump into the
route[b2b_request] on node2).
If I turn off b2b, then everything works as it should. I attached a part of
the script in the thread.

Maybe I have an error in the logic of the script?

Script snippet from node1:

loadmodule "clusterer.so"
modparam("clusterer", "db_mode", 0)
modparam("clusterer", "my_node_id", 1)
modparam("clusterer", "my_node_info", "cluster_id=1, url=bin:
192.168.56.104:5566, flags=seed")
modparam("clusterer", "neighbor_node_info", "cluster_id=1,node_id=2,url=bin:
192.168.56.105:5566")
modparam("clusterer", "sharing_tag", "anycast1/1=active")
modparam("clusterer", "seed_fallback_interval", 10)

loadmodule "b2b_entities.so"
modparam("b2b_entities", "script_req_route", "b2b_request")
modparam("b2b_entities", "script_reply_route", "b2b_reply")
modparam("b2b_entities", "db_mode", 0)
modparam("b2b_entities", "cluster_id", 1)

loadmodule "b2b_logic.so"
modparam("b2b_logic", "contact_user", 1)
modparam("b2b_logic", "db_mode", 0)

### Routing Logic 

route{

sl_send_reply(100, "Trying-1");
create_dialog();
set_dlg_sharing_tag("anycast1");

if (is_method("INVITE") && !has_totag() ) {
$du = "sip:192.168.56.106:5080";
b2b_init_request("top hiding");
exit;
}

   #route(b2b_request);
exit;
}

route[b2b_request] {

if (is_method("CANCEL")) {
sl_send_reply(100, "Canceling-1");
if (t_check_trans()) {
b2b_pass_request();

} else {
t_anycast_replicate();
}

exit;
}
}

[root@localhost opensips]# opensips-cli -x mi clusterer_list_cap
{
"Clusters": [
{
"cluster_id": 1,
"Capabilities": [
{
"name": "b2be-entities-repl",
"state": "Ok",
"enabled": "yes"
},
{
"name": "dialog-dlg-repl",
"state": "Ok",
"enabled": "yes"
},
{
"name": "tm-repl",
"state": "Ok",
"enabled": "yes"
}
]
}
]
}

[root@localhost opensips]# opensips -V
version: opensips 3.4.0-dev (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: dda7717fa
main.c compiled on 05:45:40 Jan 15 2023 with gcc 4.8.5

--

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

Re: [OpenSIPS-Users] Question on mid_registrar de-registrations

[Daren FERREIRA]

Hi Liviu

Here you are

version: opensips 3.1.13 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, 
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on  with gcc 10

Thank you

Best regards



> Le 16 janv. 2023 à 18:06, Liviu Chircu  a écrit :
> 
> On 12.01.2023 17:26, Daren FERREIRA wrote:
>> 
>> In my case, the de-registers that should be triggered are never triggered.
> 
> Hi Daren,
> 
> Please provide the output of "opensips -V", so we have something to work with 
> here.
> 
> Best regards,
> 
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
> 

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