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 <benoit.paniz...@imp.ch> 
Sent: Friday, January 20, 2023 4:07 PM
To: Alex Balashov <abalas...@evaristesys.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
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 Pratteln                Fax  +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:

Reply via email to