[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Benoit, I might not fully understand the logic, but at least for From and To header this can be easily done in a transparent way with the uac module. No need to use dialog variables for that. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -Original Message- From: Benoît Panizzon Sent: Friday, January 20, 2023 4:07 PM To: Alex Balashov Cc: Kamailio (SER) - Users Mailing List Subject: [SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout Hi Alex > I'm not familiar with this latter usage of the dialog module. Could > you explain that further? That is not a module. We use the dlg_vars to store a lot of information. I would love if there was a module taking care of symmetric number translations in all messages. I think this is a common task. Consider this situation (intentionally using invalid prefixes) Interconnection uses e164 Numbers. eg: +41661234567 for Switzerland and we use NPRN (number portability routing prefixes) numbers to route ported numbers. Customer uses 'national' notation of same number: 0661234567 Call from Customer: RURI: 0661234567 (this is ported to NPRN 99052) From: 0667776655 Call towards IC therefore has to be: RURI: +4199052661234567 From: +4166776655 So I store the original FROM and RURI in dlg_variables so I can put them back in the appropriate header when passing a RINGING or 200 OK back to the customer. Even more important. When there is a Privacy: ID Header present: I (by OFCOM regulations MUST) replace $fu and $fn with 'Anonymous' towards the customer. And of course also the Contact: Username and possibly remove PAI, PPI or whatever the customer does not need to get. But I might want to send him the Diversion Header to indicate who diverted the call, it it's privacy flag allows it of course. On any subsequent messages, re-invites, whatever else is getting sent to the customer. I have to make sure I don't disclose the calling number by mistake (customer could be logging those on his CPE). So, yes, plenty of header usernames to track and replace for all kind of messages and transactions within a dialogue. > > I noticed, when I restart kamailio after doing config changes, that > > entries kept accumulating with each restart in the 'dialog' and > > 'dialog_vars' tables, never expiring even the next day, when the > > dialog timeout we set to 12 hours should have made sure they got > > expired. > > And you're sure you've got these modparams configured correctly for > this expectation? > > https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.u > pdate_period > > https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.d > b_mode I will give it another try :-) -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
I think you might be working too hard. :-)
1. Automatic stateful reversion of From and To header modifications is
available in the `uac` module:
https://kamailio.org/docs/modules/5.6.x/modules/uac.html#uac.p.rr_from_store_param
https://kamailio.org/docs/modules/5.6.x/modules/uac.html#uac.p.restore_mode
https://kamailio.org/docs/modules/5.6.x/modules/uac.html#uac.p.restore_dlg
If you are already using these, then disregard. But if you're not, they will
take care of the reversion for you so you don't have to manually mangle any
replies or in-dialog requests.
2. R-URI is not present in replies, so this should not be relevant;
3. Most other one-way message changes specific to a given carrier or other
gateway destination can be done in branch_route, in which case the reversion to
the original value is automatic when attempting another destination.
For example:
request_route {
...
# $rU = '999';
if(method === "INVITE") {
$du = "sip:1.1.1.1:5060";
t_on_branch("MODIFY");
t_on_failure("NEXT_ONE");
t_relay();
exit;
}
}
branch_route[MODIFY] {
if($nh(d) eq "1.1.1.1")
$rU = '+999';
}
This '+999' value will be reverted when NEXT_ONE creates another branch.
-- Alex
> On Jan 20, 2023, at 10:06 AM, Benoît Panizzon wrote:
>
> Hi Alex
>
>> I'm not familiar with this latter usage of the dialog module. Could
>> you explain that further?
>
> That is not a module. We use the dlg_vars to store a lot of
> information. I would love if there was a module taking care of symmetric
> number translations in all messages. I think this is a common task.
>
> Consider this situation (intentionally using invalid prefixes)
>
> Interconnection uses e164 Numbers. eg: +41661234567 for
> Switzerland and we use NPRN (number portability routing prefixes)
> numbers to route ported numbers.
> Customer uses 'national' notation of same number: 0661234567
>
> Call from Customer:
>
> RURI: 0661234567 (this is ported to NPRN 99052)
> From: 0667776655
>
> Call towards IC therefore has to be:
>
> RURI: +4199052661234567
> From: +4166776655
>
> So I store the original FROM and RURI in dlg_variables so I can put
> them back in the appropriate header when passing a RINGING or 200 OK
> back to the customer.
>
> Even more important. When there is a Privacy: ID Header present: I (by
> OFCOM regulations MUST) replace $fu and $fn with 'Anonymous' towards the
> customer. And of course also the Contact: Username and possibly remove
> PAI, PPI or whatever the customer does not need to get. But I might
> want to send him the Diversion Header to indicate who diverted the
> call, it it's privacy flag allows it of course.
>
> On any subsequent messages, re-invites, whatever else is getting sent
> to the customer. I have to make sure I don't disclose the calling
> number by mistake (customer could be logging those on his CPE). So, yes,
> plenty of header usernames to track and replace for all kind of messages
> and transactions within a dialogue.
>
>>> I noticed, when I restart kamailio after doing config changes, that
>>> entries kept accumulating with each restart in the 'dialog' and
>>> 'dialog_vars' tables, never expiring even the next day, when the
>>> dialog timeout we set to 12 hours should have made sure they got
>>> expired.
>>
>> And you're sure you've got these modparams configured correctly for
>> this expectation?
>>
>> https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.update_period
>>
>> https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.db_mode
>
> I will give it another try :-)
>
> --
> Mit freundlichen Grüssen
>
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel +41 61 826 93 00
> CH-4133 PrattelnFax +41 61 826 93 01
> Schweiz Web http://www.imp.ch
> __
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Alex > I'm not familiar with this latter usage of the dialog module. Could > you explain that further? That is not a module. We use the dlg_vars to store a lot of information. I would love if there was a module taking care of symmetric number translations in all messages. I think this is a common task. Consider this situation (intentionally using invalid prefixes) Interconnection uses e164 Numbers. eg: +41661234567 for Switzerland and we use NPRN (number portability routing prefixes) numbers to route ported numbers. Customer uses 'national' notation of same number: 0661234567 Call from Customer: RURI: 0661234567 (this is ported to NPRN 99052) From: 0667776655 Call towards IC therefore has to be: RURI: +4199052661234567 From: +4166776655 So I store the original FROM and RURI in dlg_variables so I can put them back in the appropriate header when passing a RINGING or 200 OK back to the customer. Even more important. When there is a Privacy: ID Header present: I (by OFCOM regulations MUST) replace $fu and $fn with 'Anonymous' towards the customer. And of course also the Contact: Username and possibly remove PAI, PPI or whatever the customer does not need to get. But I might want to send him the Diversion Header to indicate who diverted the call, it it's privacy flag allows it of course. On any subsequent messages, re-invites, whatever else is getting sent to the customer. I have to make sure I don't disclose the calling number by mistake (customer could be logging those on his CPE). So, yes, plenty of header usernames to track and replace for all kind of messages and transactions within a dialogue. > > I noticed, when I restart kamailio after doing config changes, that > > entries kept accumulating with each restart in the 'dialog' and > > 'dialog_vars' tables, never expiring even the next day, when the > > dialog timeout we set to 12 hours should have made sure they got > > expired. > > And you're sure you've got these modparams configured correctly for > this expectation? > > https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.update_period > > https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.db_mode I will give it another try :-) -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
> On Jan 20, 2023, at 9:08 AM, Benoît Panizzon wrote: > > Therefore the dialog module is used to gather cdrs, but to ensure > translated numbers are translated the other way on replies and many > more. I'm not familiar with this latter usage of the dialog module. Could you explain that further? > I noticed, when I restart kamailio after doing config changes, that > entries kept accumulating with each restart in the 'dialog' and > 'dialog_vars' tables, never expiring even the next day, when the dialog > timeout we set to 12 hours should have made sure they got expired. And you're sure you've got these modparams configured correctly for this expectation? https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.update_period https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dialog.p.db_mode -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Alex > What DMQ sync issues with DB storage have you found? I haven't tried > it myself, but I would imagine a promising approach would be to have > a DMQ peer node whose sole purpose is to sync dialogs to a DB. Have > you tried that? Has it not worked out? We have two 'core' nodes handling everything that is not related to registrar and location tasks. Therefore the dialog module is used to gather cdrs, but to ensure translated numbers are translated the other way on replies and many more. I noticed, when I restart kamailio after doing config changes, that entries kept accumulating with each restart in the 'dialog' and 'dialog_vars' tables, never expiring even the next day, when the dialog timeout we set to 12 hours should have made sure they got expired. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Benoît, Having gone down this road myself, I would corroborate what Henning has to say. Getting large amounts of dialog info in bulk from the JSONRPCS API isn't a particularly good avenue, even if you can make it work with the various buffer sizes. I would also be concerned about any big locks required when iterating over the dialog structures as a whole, since they are stored in shared memory. In many cases, just because something is technically possible doesn't mean you should do it. It seems to me that `dlg.list` may be one of those RPC commands that's best suited to troubleshooting or debugging, rather than regular operational usage. (To be fair, I don't know the locking approach when reading the entire structure, and I imagine some work has gone into optimising it.) What DMQ sync issues with DB storage have you found? I haven't tried it myself, but I would imagine a promising approach would be to have a DMQ peer node whose sole purpose is to sync dialogs to a DB. Have you tried that? Has it not worked out? -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Benoit, checkout this command, you can filter here for more information, which probably is available from a customer service tool: https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dlg.r.list_match Another idea is to use that comment, which can be tuned to return only needed information: https://kamailio.org/docs/modules/5.6.x/modules/dialog.html#dlg.r.briefing Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -Original Message- From: Benoît Panizzon Sent: Friday, January 20, 2023 11:13 AM To: Henning Westerholt Cc: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout Hi Henning > not sure about your motivation in using this method on a busy > production system. Usually this is not necessary. The motivation is to provide a diagnosis tool to our customer helpdesk. (And also for me as a tech, to for example find long running calls and other stuff I might be interested in). Simplified: Customer Service enters a phone number of a customer and get an output of all settings like call forwarding (obtained from DB by our own API). But also information about registered AOR and their contacts (obtained by ul.dump) and as bonus: Information about active calls of the customer to which this phone number belongs. So I was looking for a way to gather the dialogues involving the phone number or better, AOR in question. dlg.dlg_list needs the call-id, which is not known. dlg.list_match is limited regarding what key can be used. It probably would work with trying to somehow partially matching ruri or furi, but we translate numbers, so that is a bit fuzzy and might return wrong matches or not match if clip-no-screening is used. The most promising would be to use dlg.list and then loop through the variables to find the dialogues associated with the authentication username (equal to the AOR in our case) of the customer to which the dialogue belongs to. As I kept running into DMQ sync issues with storing dialogue information in database, I switched off database support for dialogue. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Henning > not sure about your motivation in using this method on a busy > production system. Usually this is not necessary. The motivation is to provide a diagnosis tool to our customer helpdesk. (And also for me as a tech, to for example find long running calls and other stuff I might be interested in). Simplified: Customer Service enters a phone number of a customer and get an output of all settings like call forwarding (obtained from DB by our own API). But also information about registered AOR and their contacts (obtained by ul.dump) and as bonus: Information about active calls of the customer to which this phone number belongs. So I was looking for a way to gather the dialogues involving the phone number or better, AOR in question. dlg.dlg_list needs the call-id, which is not known. dlg.list_match is limited regarding what key can be used. It probably would work with trying to somehow partially matching ruri or furi, but we translate numbers, so that is a bit fuzzy and might return wrong matches or not match if clip-no-screening is used. The most promising would be to use dlg.list and then loop through the variables to find the dialogues associated with the authentication username (equal to the AOR in our case) of the customer to which the dialogue belongs to. As I kept running into DMQ sync issues with storing dialogue information in database, I switched off database support for dialogue. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
Hi Benoit,
not sure about your motivation in using this method on a busy production
system. Usually this is not necessary.
If you just want to get a statistic, there are statistics method that just give
you a counter/current calls value.
If you want to all some run-time dialog information, if you use a DB backend,
you could just look into the database.
You can also query only specific dialogs, if you are interested in only one
dialog.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-Original Message-
From: Benoît Panizzon
Sent: Friday, January 20, 2023 9:49 AM
To: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] [core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write
queue full or timeout
Hi
I'm trying to get dlg.list on a busy system via jsonrpc and xhttp.
I already increased:
tcp_conn_wq_max=2048
tcp_wq_max=20480
modparam("ctl", "binrpc_max_body_size", 2048) modparam("ctl",
"binrpc_struct_max_body_size", 2048)
But it looks like the tcp write queue overflows up at shy over 1MB reply no
matter what I change.
Any ideas what else to toggle?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G-Leiter Commerce Kunden
__
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 PrattelnFax +41 61 826 93 01
Schweiz Web http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send
an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
