I think you might be working too hard. :-)
1. Automatic stateful reversion of From and To header modifications is available in the
`uac` module:
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
<benoit.panizzon(a)imp.ch> 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…
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 Pratteln Fax +41 61 826 93 01
Schweiz Web
http://www.imp.ch
______________________________________________________