Re: [OpenSIPS-Users] Version 3.1 it stops writing cdrs

[Kingsley Tart]

In addition to Daniel's reply, on Debian (also easily available on
other Linux distros) I use keepalived, which uses VRRP under the hood.

On our OpenSIPS clusters, I use the clusterer module to replicate
dialogs and other things across several nodes, and keepalived to
maintain "floating" (virtual) IP addresses which can move from one node
to another. It's these virtual IP addresses (VIPs) that we advertise as
the addresses for our SIP proxies.

keepalived is configured with several tests, which it polls every
couple of seconds. These tests include things like whether the node is
administratively enabled or disabled (a 0 or 1 in a status file),
whether OpenSIPS is responsive (a script to send a UDP packet to
OpenSIPS and see whether there's a response) and other things.

We have other tests but I don't want to over complicate things here.

If a node becomes less favourable (eg administratively disabled,
OpenSIPS not responding), keepalived moves the VIP to another node.
This, in conjunction with OpenSIPS clustering (the clusterer module)
means that service continues without interruption[1][2]

[1] eg you can mark your node as disabled, wait for the VIP to move to
another node, then restart OpenSIPS

[2] OpenSIPS clustering doesn't replicate early dialogs, so if your VIP
moves whilst there are early dialogs, those calls will be lost when the
VIP moves to another node. I have built some extra stuff to avoid this
problem when we want to restart a node, but I don't want to over
complicate this email.

I strongly recommend you look into keepalived, and if you do this, also
add (this on debian) net.ipv4.ip_nonlocal_bind=1 into sysctl (for IPv4
sockets).

Cheers,
Kingsley.

On Wed, 2023-02-15 at 13:18 -0500, Saint Michael wrote:
> what is VRRP ?
> 
> On Wed, Feb 15, 2023 at 1:16 PM Kingsley Tart 
> wrote:
> > FWIW, I set up OpenSIPS here in a couple of clusters with VRRP
> > managing
> > the service "floating" IP addresses. If I want to restart a node, I
> > mark it as disabled, which then means that
> > 
> > * it stops replying to OPTIONS
> > * it responds 503 to INVITE if other nodes are still up
> > * when all early dialogs have ended, the IP moves to another node
> > 
> > I can then restart OpenSIPS on this node without losing anything.
> > 
> > Cheers,
> > Kingsley.
> > 
> > On Thu, 2023-01-12 at 23:29 -0500, Saint Michael wrote:
> > > Is there a command that I may run without restarting opensips
> > that
> > > restarts the process, internally?
> > > if I restart opensips I lose all the records.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] Version table

[Kingsley Tart]

Could you set up a federated table on the separate database that maps
to the version table on the DB server that has this table?

Cheers,
Kingsley.

On Tue, 2023-02-14 at 10:14 +, Pat M via Users wrote:
> Hello
> 
> I am using auth_db and querying a seperate mysql database that does
> not have the version table
> is there a way to ignore that table? or can i make a seperate
> connection to a local db just for version?
> 
> Thanks 
> Pat
> 
> Sent with Proton Mail secure email.
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] Version 3.1 it stops writing cdrs

[Kingsley Tart]

FWIW, I set up OpenSIPS here in a couple of clusters with VRRP managing
the service "floating" IP addresses. If I want to restart a node, I
mark it as disabled, which then means that

* it stops replying to OPTIONS
* it responds 503 to INVITE if other nodes are still up
* when all early dialogs have ended, the IP moves to another node

I can then restart OpenSIPS on this node without losing anything.

Cheers,
Kingsley.

On Thu, 2023-01-12 at 23:29 -0500, Saint Michael wrote:
> Is there a command that I may run without restarting opensips that
> restarts the process, internally?
> if I restart opensips I lose all the records.


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

Re: [OpenSIPS-Users] rtpengine not kernel packet forwarding

[Kingsley Tart]

Oh wow, it was just a case of hanging on the test call for a bit longer
- thank you so much!

I never saw that crucial bit of info in any of the guides I found and
it's perhaps a bit odd that the distro scripts added the 1st and 3rd
(as quoted below) rules to iptables but didn't add the last one.

Anyway, it does indeed seem that after a few seconds it switches over
to kernel forwarding, so thank you once again - you have successfully
managed to postpone my balding process ;)

Cheers,
Kingsley.

On Mon, 2023-01-23 at 07:48 -0600, John Burke via Users wrote:
> The kernel module still requires a fallback user space rule for the
> first few packets. Once the user space daemon determines the
> forwarding rule set, it pushes to the kernel module. The kernel
> module can then pickup the packets. Their GitHub page has a detailed
> step by step for this process.
> 
> -A INPUT -p udp -j rtpengine
> -A rtpengine -p udp -m udp --dport 2223 -m set --match-set allowed-
> rtp-management src -j ACCEPT
> -A rtpengine -p udp -j RTPENGINE --id 0
> -A rtpengine -p udp -j ACCEPT
> 
> 
> 
> Sent from my iPhone
> 
> > On Jan 23, 2023, at 7:27 AM, Kingsley Tart 
> > wrote:
> > A rtpengine -p udp -j ACCEPT
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] rtpengine not kernel packet forwarding

[Kingsley Tart]

Hi,

I realise this is an OpenSIPS list and not an rtpengine list, but I'm
stumped so am wondering whether anyone on here can shed any light on
the issue.

I have rtpengine working with OpenSIPS but if I try to use kernel
packet forwarding it doesn't forward the packets.

lsmod shows xt_RTPENGINE and x_tables loaded.

With this in iptables, rtpengine works but forwards packets in user
space:

:rtpengine - [0:0]
-A INPUT -p udp -j rtpengine
-A rtpengine -p udp -m udp --dport 2223 -m set --match-set 
allowed-rtp-management src -j ACCEPT
A rtpengine -p udp -j ACCEPT

With this in iptables, no packets get forwarded:

:rtpengine - [0:0]
-A INPUT -p udp -j rtpengine
-A rtpengine -p udp -m udp --dport 2223 -m set --match-set 
allowed-rtp-management src -j ACCEPT
-A rtpengine -p udp -j RTPENGINE --id 0

/proc/rtpengine/0/list exists but remains empty. /proc/rtpengine/list
only ever contains a zero.

This is on Debian 11. rtpengine version is 10.5.3.1-1. This is in apt
sources:

deb [signed-by=/usr/share/keyrings/dfx.at-rtpengine-archive-keyring.gpg] 
https://dfx.at/rtpengine/10.5 bullseye main


Any pointers would be greatly appreciated!

Thanks in advance.

-- 
Cheers,
Kingsley.


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

[OpenSIPS-Users] disabling / filtering some logs

[Kingsley Tart]

Hi,

Is it possible to filter what gets logged into syslog, with more fine
grained detail than just setting the log level?

I have essentially this code:

if (!validate_dialog()) {
if ($rc == -4) {
send_reply(481, "Call does not exist");
exit;
} else if (!fix_route_dialog()) {
xlog("L_WARN", "$cfg_file/$cfg_line @ $Tsm: failed to fix route dialog; 
rc=$rc\n");
send_reply(488, "Unable to fix dialog");
exit;
}

I'm getting loads of entries in opensips.log where validate_dialog()
fails with rc -2 but the call still works because fix_route_dialog() is
successful, eg:

ERROR:dialog:dlg_validate_dialog: failed to validate remote contact: 
dlg=[sip:65.151.23.22:5060] , req=[sip:65.151.23.22:5060;user=phone]

I would prefer to not have opensips.log littered with these, but still
want to see other errors.

Is this possible?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] append body to reply?

[Kingsley Tart]

Hi,

thanks - I hunted through docs and googled for several hours but didn't
find that, though I did figure out that sipmsgops wasn't the answer.

Cheers,
Kingsley.

On Thu, 2022-10-20 at 15:41 +0300, Bogdan-Andrei Iancu wrote:
> Hi Kingsley,
> 
> Docs are your best friend:
> 
https://opensips.org/html/docs/modules/3.2.x/tm.html#func_t_reply_with_body
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS Bootcamp 5-16 Dec 2022, online
>https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/
> 
> On 10/20/22 2:08 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > Is it possible with OpenSIPS to append a body to a reply? If so, is
> > there also an equivalent of $ml for how long the outbound reply
> > would
> > be? (I appreciate that until send_reply() is called, the exact size
> > would be impossible to calculate).
> > 
> > I'm finding it useful to use custom INFO calls to share metadata
> > with
> > some of our other hosts. I could add the info in headers, but the
> > message body in some cases seems more appropriate.
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 


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

[OpenSIPS-Users] append body to reply?

[Kingsley Tart]

Hi,

Is it possible with OpenSIPS to append a body to a reply? If so, is
there also an equivalent of $ml for how long the outbound reply would
be? (I appreciate that until send_reply() is called, the exact size
would be impossible to calculate).

I'm finding it useful to use custom INFO calls to share metadata with
some of our other hosts. I could add the info in headers, but the
message body in some cases seems more appropriate.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] turn off syslog logging with OpenSIPS 3.2 ?

[Kingsley Tart]

Hi,

Thanks. I presume from your answer that OpenSIPS will always talk to
syslog regardless of what logging settings I configure within OpenSIPS.
Did I read that right?

If that's the case, I'm probably better off not telling OpenSIPS to log
to a local file itself and split it out within syslog's config. I
expect that would be more efficient than OpenSIPS writing the log to
two places and then have one of those places (syslog) ignore what it's
being given.

There's stuff I need to learn about how to configure syslog but at
least your answer has given me some pointers, thanks.

Cheers,
Kingsley.

On Mon, 2022-10-17 at 12:08 -0400, Ovidiu Sas wrote:
> Hello Kingsley,
> 
> You need to disable logging from local0 into /var/log/syslog.
> Check you (r)syslog.conf file (whatever that is on you OS) and add
> "local0.none" for /var/log/syslog
> 
> Example:
> *.*;auth,authpriv,\
> local0,local1.none  -/var/log/syslog
> 
> Hope this helps,
> -ovidiu
> 
> On Mon, Oct 17, 2022 at 8:19 AM Kingsley Tart 
> wrote:
> > 
> > Hi,
> > 
> > is there a way in OpenSIPS 3.2 of logging to /var/log/opensips.log
> > but
> > not copy these logs into syslog?
> > 
> > I have these log settings:
> > 
> > log_level=3
> > xlog_level=1
> > log_stderror=no
> > log_facility=LOG_LOCAL0
> > 
> > What I'm seeing is opensips logs in /var/log/opensips.log but every
> > entry in there is duplicated in /var/log/syslog; I don't want them
> > in
> > there.
> > 
> > Is there a way in OpenSIPS to configure this, or should I instead
> > tell
> > OpenSIPS to log using LOG_DAEMON and configure syslog to split
> > opensips
> > logs out itself?
> > 
> > I've tried googling and looking at the OpenSIPS docs but can't find
> > the
> > answer.
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> 


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

[OpenSIPS-Users] turn off syslog logging with OpenSIPS 3.2 ?

[Kingsley Tart]

Hi,

is there a way in OpenSIPS 3.2 of logging to /var/log/opensips.log but
not copy these logs into syslog?

I have these log settings:

log_level=3
xlog_level=1
log_stderror=no
log_facility=LOG_LOCAL0

What I'm seeing is opensips logs in /var/log/opensips.log but every
entry in there is duplicated in /var/log/syslog; I don't want them in
there.

Is there a way in OpenSIPS to configure this, or should I instead tell
OpenSIPS to log using LOG_DAEMON and configure syslog to split opensips
logs out itself?

I've tried googling and looking at the OpenSIPS docs but can't find the
answer.

Cheers,
Kingsley.


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

[OpenSIPS-Users] high res timestamps in /var/log/opensips log entries

[Kingsley Tart]

Hi,

is it possible to get log entries in /var/log/opensips.log to include
high res timestamps?

I'm not talking about log entries that I create myself with xlog(), but
ones that OpenSIPS itself generates when something fails, for example.

I would find it useful to check more precise timing of errors to the
high res timestamps available when looking at packet times in a pcap.

Cheers,
Kingsley.


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

[OpenSIPS-Users] why is request timeout a 4xx error?

[Kingsley Tart]

Obviously there's no point in trying to change it, but shouldn't a
request timeout be a 5xx or 6xx error, not 408?

I thought 4xx errors were client errors, but downstream timeouts are
not the fault of the client.

Just a point of interest really.

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] [RELEASE] OpenSIPS 3.1.8 and 3.2.5 minor releases

[Kingsley Tart]

Hi,

Do you have a link to the changelog for 3.1.8? I couldn't find it.

Cheers,
Kingsley.

On Wed, 2022-02-09 at 13:15 +0200, Răzvan Crainea wrote:
> Hi, everyone!
> 
> OpenSIPS 3.1.8 and 3.2.5 minor versions are planned to be released in 
> two weeks, on Wednesday, 23rd of February 2022.
> Starting today until the release day, we are putting a freeze on any new 
> commits, unless they are addressing fully tested bug fixes.
> 
> Best regards,


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

[OpenSIPS-Users] WARNING:drouting:dr_recv_sync_packet errors after dr_reload

[Kingsley Tart]

Hi,

When I do a dr_reload it seems to work OK but I get lots of warnings in
the logs. For example, I did dr_reload on node 3. Node 4 logged this:

Feb  5 12:58:33 ipx-d /usr/sbin/opensips[428]: 
INFO:clusterer:handle_sync_request: Received sync request for capability 
'drouting-status-repl' from node 3, cluster 1
Feb  5 12:58:33 ipx-d /usr/sbin/opensips[428]: INFO:clusterer:send_sync_repl: 
Sent all sync packets for capability 'drouting-status-repl' to node 3, cluster 1

Node 3 (the one I'd done a reload on) logged this:

Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23767]: INFO:drouting:dr_reload_cmd: 
dr_reload MI command received!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23767]: 
INFO:drouting:dr_reload_data_head: loading drouting data!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23767]: 
INFO:drouting:dr_reload_data_head: loading drouting data!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23767]: INFO:clusterer:send_sync_req: 
Sent sync request for capability 'drouting-status-repl' to node 4, cluster 1
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23803]: 
INFO:clusterer:handle_sync_packet: Received all sync packets for capability 
'drouting-status-repl' in cluster 1
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23803]: 
INFO:drouting:receive_dr_cluster_event: Synchronized carriers and gateways 
status from cluster
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 ipx-c /usr/sbin/opensips[23770]: 
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Feb  5 12:58:33 

Re: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7

[Kingsley Tart]

On Fri, 2022-01-28 at 19:52 +0200, Liviu Chircu wrote:
> On 28.01.2022 19:22, Kingsley Tart wrote:
> > Wow yes thank you! I've been trying to get this to work on and off
> > for weeks!
> 
> Always read the module docs[1] when in doubt.  All of this is
> documented in section 1.1.4.3 of drouting 3.1 docs, including a
> pointer to the iCalendar RFC.
> [1]: https://opensips.org/docs/modules/3.1.x/drouting.html#idp165696

Thanks, but I had read that document over and over, and well, the RFC
is over 140 pages ... I sort of got lost in it.

Some examples within the docs would have been useful.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7

[Kingsley Tart]

On Fri, 2022-01-28 at 18:55 +0200, Liviu Chircu wrote:
> Hi Kingsley,
> The 3.1 release is the final release using the classic timerec
> support.  Since 3.2, the time recurrence parsing and evaluation is
> much more consistent and well-tested across all modules using this
> concept.
> Still, in order to fix your issue on 3.1, the format I linked is the
> ONLY way in order to define an [A, B) interval, where B is non-
> inclusive.  Looking at your examples, both strings seem wrong
> ("20220124T00|404999" and "20220128T163000|504096247"), because
> of the poorly formatted DURATION field -- the second one.  Example
> correct strings for that field: P7W (7 weeks), PT24H (24 hours),
> PT1M30S (1 minute 30 seconds), etc..  The official format is detailed
> here[1].  Fun fact: MySQL's Galera engine uses this exact format as
> well, in order to represent time durations in its config file.
> [1]: https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.6
> Hope this helps,

Wow yes thank you! I've been trying to get this to work on and off for
weeks!

This did the trick:

++-+--+---+--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec   | 
priority | routeid | gwlist | sort_alg | sort_profile | attrs| 
description |
++-+--+---+--+-++--+--+--+-+
|200 | 0   | 441476292509 | 20220124T00|P4DT17H22M|
1 | NULL| #gw9   | N| NULL | endpoint=gw9 | NULL|
|201 | 0   | 441476292509 | 20220128T172200|PT1M  |
1 | NULL| #gw1   | N| NULL | endpoint=gw1 | NULL|
|202 | 0   | 441476292509 | 20220128T172300|P7101W3DT6H28M15S |
1 | NULL| #gw9   | N| NULL | endpoint=gw9 | NULL|
++-+--+---+--+-++--+--+--+-+

I can stop pulling my hair out and cancel the order for that wig ... ;)

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

[OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7

[Kingsley Tart]

Hi,

I'm getting nowhere with timerec things with do_routing(). This is with
OpenSIPS 3.1.7.

I have no need for any daily or weekly recurrences. All I'm trying to
do is have a rule apply between two date-times, eg from 2022-01-01
01:00:00 until 2023-04-01 12:00:00 or whatever.

I have tried each of the below options, but with each one, do_routing()
always just picks the first rule, even when the timerecs say (if I'd
got the format correct) the second rule should apply.

Does anyone know what I should put into a rule in order for it to just
apply 24/7 from one date and time to another?

None of these worked:

++-+--+---+--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec   | priority | 
routeid | gwlist | sort_alg | sort_profile | attrs| description |
++-+--+---+--+-++--+--+--+-+
|173 | 0   | 441476292509 | 20220124T00|404999|1 | NULL 
   | #gw9   | N| NULL | endpoint=gw9 | NULL|
|174 | 0   | 441476292509 | 20220128T163000|504096247 |1 | NULL 
   | #gw1   | N| NULL | endpoint=gw1 | NULL|
++-+--+---+--+-++--+--+--+-+

++-+--+---+--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec   | 
priority | routeid | gwlist | sort_alg | sort_profile | attrs| 
description |
++-+--+---+--+-++--+--+--+-+
|164 | 0   | 441476292509 | 20220124T00|||20220128T154959 |
1 | NULL| #gw9   | N| NULL | endpoint=gw9 | NULL|
|165 | 0   | 441476292509 | 20220128T155000|||1231T235959 |
1 | NULL| #gw1   | N| NULL | endpoint=gw1 | NULL|
++-+--+---+--+-++--+--+--+-+

++-+--++--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec| 
priority | routeid | gwlist | sort_alg | sort_profile | attrs| 
description |
++-+--++--+-++--+--+--+-+
|161 | 0   | 441476292509 | 20220124T00|0||20220128T154859 |
1 | NULL| #gw9   | N| NULL | endpoint=gw9 | NULL|
|162 | 0   | 441476292509 | 20220128T154900|0||1231T235959 |
1 | NULL| #gw1   | N| NULL | endpoint=gw1 | NULL|
++-+--++--+-++--+--+--+-+

++-+--++--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec| 
priority | routeid | gwlist | sort_alg | sort_profile | attrs| 
description |
++-+--++--+-++--+--+--+-+
|152 | 0   | 441476292509 | 20220124T00|1||20220128T154559 |
1 | NULL| #gw9   | N| NULL | endpoint=gw9 | NULL|
|153 | 0   | 441476292509 | 20220128T154600|1||1231T235959 |
1 | NULL| #gw1   | N| NULL | endpoint=gw1 | NULL|
++-+--++--+-++--+--+--+-+

++-+--++--+-++--+--+--+-+
| ruleid | groupid | prefix   | timerec| 
priority | routeid | gwlist | sort_alg | sort_profile | attrs| 
description |
++-+--++--+-++--+--+--+-+
|155 | 0   | 441476292509 | 20220124T00|86400||20220128T154659 |
1 | NULL| #gw9   | N| NULL | 

Re: [OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster?

[Kingsley Tart]

OK thanks - I won't be doing that then. I thought it might  have been
an option as I'm getting nowhere with the timerec on 3.1.7 and
do_routing().

Cheers,
Kingsley.

On Fri, 2022-01-28 at 09:15 +0200, Bogdan-Andrei Iancu wrote:
> Hi,
> 
> I would definitely not advise this. There may be differences in the
> BIN 
> proto or on how the modules are packing data for replication.
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS eBootcamp
>https://www.opensips.org/Training/Bootcamp
> 
> On 1/27/22 5:05 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > I have a 4 node cluster running OpenSIPS 3.1.7.
> > 
> > Is it OK to upgrade one node to 3.2.4 for a while for soak testing
> > while leaving the others at 3.1.7?
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 


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

[OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster?

[Kingsley Tart]

Hi,

I have a 4 node cluster running OpenSIPS 3.1.7.

Is it OK to upgrade one node to 3.2.4 for a while for soak testing
while leaving the others at 3.1.7?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] can't get timerec to work in dynamic routing

[Kingsley Tart]

Right OK thanks. I've never set that up before; I'll see how I get on.

Thanks once again.

Cheers,
Kingsley.

On Tue, 2022-01-18 at 14:57 +0200, Bogdan-Andrei Iancu wrote:
> Googling may not help you too much as the encoding of the timerec is 
> opensips specific, even if the concepts are from the RFC.
> 
> CP -> OpenSIPS Control Panel web interface 
> http://controlpanel.opensips.org/ , it has a Dynamic Routing 
> provisioning tool.
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS eBootcamp 2021
>https://opensips.org/training/OpenSIPS_eBootcamp_2021/
> 
> On 1/18/22 2:50 PM, Kingsley Tart wrote:
> > Hi Bogdan,
> > 
> > Thanks.
> > 
> > I have tried a number of google phrases to try to find a timerec
> > builder (and also an interpreter so that I can test my own values)
> > but
> > I have been unable to find anything that seems relevant.
> > 
> > What is CP?
> > 
> > Cheers,
> > Kingsley.
> > 
> > On Tue, 2022-01-18 at 14:41 +0200, Bogdan-Andrei Iancu wrote:
> > > Hey Kingsley,
> > > 
> > > My 2 cents on the matter - have you tried to use CP in order to
> > > encode
> > > the desired timerec part?
> > > 
> > > Regards,
> > > 
> > > Bogdan-Andrei Iancu
> > > 
> > > OpenSIPS Founder and Developer
> > > https://www.opensips-solutions.com
> > > OpenSIPS eBootcamp 2021
> > > https://opensips.org/training/OpenSIPS_eBootcamp_2021/
> > > 
> > > On 1/12/22 8:59 PM, Kingsley Tart wrote:
> > > > Hi,
> > > > 
> > > > I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic
> > > > routing
> > > > rules but am struggling to understand the timerec and get it
> > > > working.
> > > > 
> > > > The intention here is that from 2000-01-01 00:00:00 to 2022-01-
> > > > 12
> > > > 18:34:59 then prefix 441476292508 will go to gw9, but after
> > > > that it
> > > > will go to gw8. This is for all times of day and all days of
> > > > the
> > > > week.
> > > > 
> > > > This is what I have in the appropriate partition:
> > > > 
> > > > ++-+--+--
> > > > 
> > > > -++
> > > > > ruleid | groupid | prefix   |
> > > > > timerec   | gwlist |
> > > > 
> > > > ++-+--+--
> > > > 
> > > > -++
> > > > >  88 | 0   | 441476292508 |
> > > > > 2101T00|||20220112T183459 | #gw9   |
> > > > >  89 | 0   | 441476292508 |
> > > > > 20220112T183500|||1231T235959 | #gw8   |
> > > > 
> > > > ++-+--+--
> > > > 
> > > > -++
> > > > 
> > > > However, even though the time and date has now passed 2022-01-
> > > > 12
> > > > 18:34:59, it is still sending to gw9. The new rule seems to be
> > > > being
> > > > ignored.
> > > > 
> > > > I did dr_reload and even completely restarted OpenSIPS.
> > > > 
> > > > Any idea what I am doing wrong here?
> > > > 
> > > > Cheers,
> > > > Kingsley.
> > > > 
> > > > 
> > > > ___
> > > > Users mailing list
> > > > Users@lists.opensips.org
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 


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

[OpenSIPS-Users] can't get timerec to work in dynamic routing

[Kingsley Tart]

Hi,

I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic routing
rules but am struggling to understand the timerec and get it working.

The intention here is that from 2000-01-01 00:00:00 to 2022-01-12
18:34:59 then prefix 441476292508 will go to gw9, but after that it
will go to gw8. This is for all times of day and all days of the week.

This is what I have in the appropriate partition:

++-+--+---++
| ruleid | groupid | prefix   | timerec   | gwlist |
++-+--+---++
| 88 | 0   | 441476292508 | 2101T00|||20220112T183459 | #gw9   |
| 89 | 0   | 441476292508 | 20220112T183500|||1231T235959 | #gw8   |
++-+--+---++

However, even though the time and date has now passed 2022-01-12
18:34:59, it is still sending to gw9. The new rule seems to be being
ignored.

I did dr_reload and even completely restarted OpenSIPS.

Any idea what I am doing wrong here?

Cheers,
Kingsley.


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

[OpenSIPS-Users] can't get timerec to work in dynamic routing

[Kingsley Tart]

Hi,

I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic routing
rules but am struggling to understand the timerec and get it working.

The intention here is that from 2000-01-01 00:00:00 to 2022-01-12
18:34:59 then prefix 441476292508 will go to gw9, but after that it
will go to gw8. This is for all times of day and all days of the week.

This is what I have in the appropriate partition:

++-+--+---++
| ruleid | groupid | prefix   | timerec   | gwlist |
++-+--+---++
| 88 | 0   | 441476292508 | 2101T00|||20220112T183459 | #gw9   |
| 89 | 0   | 441476292508 | 20220112T183500|||1231T235959 | #gw8   |
++-+--+---++

However, even though the time and date has now passed 2022-01-12
18:34:59, it is still sending to gw9. The new rule seems to be being
ignored.

I did dr_reload and even completely restarted OpenSIPS.

Any idea what I am doing wrong here?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] Parse P-Asserted-Identity

[Kingsley Tart]

That's interesting - I'm more accustomed to seeing those tags on an
RPID header than PAID. With PAID I would have expected a separate
Privacy header to contain the "id" string.

Is this still OK with the RFCs?

Cheers,
Kingsley.

On Mon, 2021-11-29 at 13:22 +0100, Mickael MONSIEUR wrote:
> Hello,
> 
> My provider add to my INVITE's :
> 
> P-Asserted-Identity: "Anonymous"
> ;party=calling;privacy=yes;screen=no
> 
> Whether the call should be Anonymized to end-users.
> 
> How to get the value of "privacy" ?
> 
> I try:
> 
> if( $(ai{privacy}) == "yes" )
> 
> But it does not work. (error when starting opensips)
> 
> Thanks
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] one node in 3 node cluster thinks all gateways are down

[Kingsley Tart]

Hi,

I have a 3 node cluster of OpenSIPS 3.1.6 with VIPs maintained by
keepalived. Each has its own preferred VIP but will take on others if
other nodes become unavailable. Primarily, node A has 'vip-a', node B
has 'vip-b', and node C has 'vip-c'.

Node A is normally the one doing gateway probing:

modparam("drouting", "cluster_sharing_tag", "vip-a")

Right now, node A still has vip-a and is doing the gateway probing.
Node A and node B both consider all gateways active, but node C
considers them all inactive.

Node C is still receiving messages from the cluster, so I don't
understand why this is, given that it's only node A that's doing the
probing (I've verified this with ngrep) - only node A is originating
OPTIONS messages).

Any clues?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] user script trace option in xlog?

[Kingsley Tart]

On Wed, 2021-10-27 at 13:11 +0300, Liviu Chircu wrote:
> On 27.10.2021 12:17, Kingsley Tart wrote:
> > Thanks - that looks useful, except that it no longer seems to be
> > present in OpenSIPS, at least with 3.1.x which is the version I'm
> > using. I can see from the docs that it's available in 2.2.x. I haven't
> > been able to find the equivalent in 3.1.x yet.
> 
> Docs for $cfg_line: 
> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc102
> 
> I double-checked and it's in the code as well, so it SHOULD work.  Let 
> me know if this is not the case anymore and I'll have a closer look.
> 
> Best,

Yes that works, thanks.

Previously I had googled "opensips cfg_line" as I find it the easiest
way of searching when I don't know what component of OpenSIPS something
might be in. However, that took me here, where it's listed as a
parameter not a variable in that version of OpenSIPS, so I was treating
it the same:

https://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc32

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] user script trace option in xlog?

[Kingsley Tart]

On Tue, 2021-10-26 at 19:25 +0300, Liviu Chircu wrote:
> Hi,
> 
> Sounds to me like you need a route invocation backtrace, which is 
> immediately available via the $(route[*]) construct.  See the docs [1] 
> for more details.
> 
> Disclaimer: no line numbers are provided, only the list of route names 
> that led up to the current execution point.
> 
> [1]: https://www.opensips.org/Documentation/Script-CoreVar-3-3#toc96

Hi,

this is a classic case of Murphy's Law I think :)

As far as I can make out, this was introduced in OpenSIPS 3.2, but I'm
running 3.1.6!

It would be useful if it was there for me though.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] user script trace option in xlog?

[Kingsley Tart]

On Mon, 2021-10-25 at 23:35 +0200, Karsten Horsmann wrote:
> Hi Kingsley, 
> 
> You could use 
> cfg_line
> 
> 
> to return your linenumber in the script via xlog. 

Hi,

Thanks - that looks useful, except that it no longer seems to be
present in OpenSIPS, at least with 3.1.x which is the version I'm
using. I can see from the docs that it's available in 2.2.x. I haven't
been able to find the equivalent in 3.1.x yet.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

On Tue, 2021-10-26 at 11:16 +0300, Liviu Chircu wrote:
> Hi,
> 
> On 26.10.2021 11:12, Kingsley Tart wrote:
> > root@ipx-a:/tmp# gdb ./ core.opensips.107.1635217462.23482
> 
> I think I figured out what's wrong... why are you using this "./" 
> construct?!  That argument MUST be the binary that produced the 
> corefile, which is typically /usr/sbin/opensips!  If you look below, gdb 
> even briefly complains about this:
> > ./: Is a directory.
> 
> Did you get this instruction from the website?  Let me know if there is 
> anything to correct on that side.
> 
> Hope this helps,

Issue reported:

https://github.com/OpenSIPS/opensips/issues/2666

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

On Tue, 2021-10-26 at 11:16 +0300, Liviu Chircu wrote:
> Hi,
> 
> On 26.10.2021 11:12, Kingsley Tart wrote:
> > root@ipx-a:/tmp# gdb ./ core.opensips.107.1635217462.23482
> 
> I think I figured out what's wrong... why are you using this "./" 
> construct?!  That argument MUST be the binary that produced the 
> corefile, which is typically /usr/sbin/opensips!  If you look below, gdb 
> even briefly complains about this:
> > ./: Is a directory.
> 
> Did you get this instruction from the website?  Let me know if there is 
> anything to correct on that side.
> 
> Hope this helps,

Aha!

Yes, I'm getting a full trace now, thanks.

I didn't notice the error in gdb's output as it got lost amongst the
other messages. I've never used gdb before so I thought all of this
output was normal.

The web site (
https://www.opensips.org/Documentation/TroubleShooting-Crash) mentioned
this:

gdb /usr/local/sbin/opensips core.6645

but on my system the binary is /usr/sbin/opensips. I've been juggling a
lot in my mind recently and I imagined that /usr/local/sbin/opensips
was just a directory containing the core file or something.

Anyway, I can now report the crashes with proper traces - 
https://github.com/OpenSIPS/opensips/issues I presume.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

On Mon, 2021-10-25 at 19:21 +0300, Liviu Chircu wrote:
> On 25.10.2021 17:52, Kingsley Tart wrote:
> > OpenSIPS 3.1.5 is crashing a lot on Debian 10.
> 
> Hi Kingsley,
> 
> In 3.1.6 there are some critical fixes in the auth, auth_db and 
> mid-registrar modules.  If you are using any of those, I highly 
> recommend you upgrade to it first, before investing any more time on 
> these corefiles.
> 
> Regarding your corefile issue, it is definitely uncommon, the basic 
> "opensips" + "opensips-dbg" package recipe should be enough for you to 
> visualize at least a backtrace out of an OpenSIPS corefile.  One guess 
> would be that you are also installing an "opensips" binary through "make 
> install" on the same box, which is not symbol-compatible with the 
> "opensips-dbg" debugging package.  Could this be the case?
> 
> Best,

Hi. Unfortunately this is still happening. This is OpenSIPS 3.1.6 now.
And the symbols aren't matching either, which is odd as you say.

You can see from the timestamps on the core files how often this is
happening, and this isn't actually carrying live calls yet - it's just
forwarding OPTIONS messages.

root@ipx-a:/tmp# ls -l
total 596056
-rw--- 1 opensips opensips 81145856 Oct 25 15:34 
core.opensips.107.1635172491.18078
-rw--- 1 opensips opensips 79904768 Oct 25 15:55 
core.opensips.107.1635173727.18884
-rw--- 1 opensips opensips 79908864 Oct 25 17:27 
core.opensips.107.1635179240.5190
-rw--- 1 opensips opensips 79904768 Oct 25 18:20 
core.opensips.107.1635182431.24581
-rw--- 1 opensips opensips 81149952 Oct 25 20:57 
core.opensips.107.1635191841.25806
-rw--- 1 opensips opensips 81281024 Oct 26 03:02 
core.opensips.107.1635213742.9541
-rw--- 1 opensips opensips 81149952 Oct 26 04:04 
core.opensips.107.1635217462.23482
-rwxr-xr-x 1 root root   97 Aug 23 17:07 dialog_show.sh
-rw-r--r-- 1 root root   109339 Oct 26 04:04 notify-vip.log
-rw-r--r-- 1 root root 67030692 Oct 25 15:36 
opensips-at-2021-10-25_153500.tar.gz
prw-rw-rw- 1 opensips opensips0 Oct 26 04:04 opensips_fifo
drwx-- 3 root root 4096 Aug 13 10:40 
systemd-private-ff846758639f451e8ab388f88ce4b70c-openntpd.service-lGfMed
root@ipx-a:/tmp# gdb ./ core.opensips.107.1635217462.23482
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
./: Is a directory.
[New LWP 23482]
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f 
/etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x559bc2b741ab in ?? ()
(gdb) bt full
#0  0x559bc2b741ab in ?? ()
No symbol table info available.
#1  0x7fe9f919bfb8 in ?? ()
No symbol table info available.
#2  0x20504455000b in ?? ()
No symbol table info available.
#3  0x in ?? ()
No symbol table info available.
(gdb)

Cheers,
Kingsley.


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

[OpenSIPS-Users] user script trace option in xlog?

[Kingsley Tart]

Hi,

Is there something that I can put in an xlog() call that will show the
trace of calling lines, a bit like "cluck" in Perl's Carp module?

eg if I want to xlog an error, it would be handy for debugging purposes
to do something like

xlog("L_WARN", "You did a silly thing", 1);

and in the logs, see something like

You did a silly thing
  at opensips.cfg line 2623
  at opensips.cfg line 1874
  at opensips.cfg line 723

where line 2623 is the line with the xlog() call, line 1874 is the line
that called the function that made the xlog() call, and line 723 is the
line that called the function that line 1874 is in.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

On Mon, 2021-10-25 at 19:21 +0300, Liviu Chircu wrote:
> On 25.10.2021 17:52, Kingsley Tart wrote:
> > OpenSIPS 3.1.5 is crashing a lot on Debian 10.
> 
> Hi Kingsley,
> 
> In 3.1.6 there are some critical fixes in the auth, auth_db and 
> mid-registrar modules.  If you are using any of those, I highly 
> recommend you upgrade to it first, before investing any more time on 
> these corefiles.
> 
> Regarding your corefile issue, it is definitely uncommon, the basic 
> "opensips" + "opensips-dbg" package recipe should be enough for you to 
> visualize at least a backtrace out of an OpenSIPS corefile.  One guess 
> would be that you are also installing an "opensips" binary through "make 
> install" on the same box, which is not symbol-compatible with the 
> "opensips-dbg" debugging package.  Could this be the case?
> 
> Best,
> 

Hi. I've upgraded anyway. I'll see how this pans out.

After this operation, 34.8 kB of additional disk space will be used.
Get:1 https://apt.opensips.org buster/3.1-releases amd64 opensips-regex-module 
amd64 3.1.6-1 [181 kB]
Get:2 https://apt.opensips.org buster/3.1-releases amd64 opensips-perl-modules 
amd64 3.1.6-1 [221 kB]
Get:3 https://apt.opensips.org buster/3.1-releases amd64 opensips-mysql-module 
amd64 3.1.6-1 [208 kB]
Get:4 https://apt.opensips.org buster/3.1-releases amd64 opensips-http-modules 
amd64 3.1.6-1 [271 kB]
Get:5 https://apt.opensips.org buster/3.1-releases amd64 
opensips-dialplan-module amd64 3.1.6-1 [204 kB]
Get:6 https://apt.opensips.org buster/3.1-releases amd64 opensips-dbg amd64 
3.1.6-1 [23.2 MB]
Get:7 https://apt.opensips.org buster/3.1-releases amd64 opensips amd64 3.1.6-1 
[3,712 kB]
Get:8 https://apt.opensips.org buster/cli-nightly amd64 opensips-cli all 
0.1~20211021~c828ade-1 [40.1 kB]
Fetched 28.0 MB in 1s (21.1 MB/s)

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

On Mon, 2021-10-25 at 19:21 +0300, Liviu Chircu wrote:
> On 25.10.2021 17:52, Kingsley Tart wrote:
> > OpenSIPS 3.1.5 is crashing a lot on Debian 10.
> 
> Hi Kingsley,
> 
> In 3.1.6 there are some critical fixes in the auth, auth_db and 
> mid-registrar modules.  If you are using any of those, I highly 
> recommend you upgrade to it first, before investing any more time on 
> these corefiles.

Hi,

Thanks. I don't believe I'm using any of those modules. This is what I
have:

root@ipx-a:/tmp# grep loadmodule /etc/opensips/opensips.cfg | sort
loadmodule "acc.so"
loadmodule "avpops.so"
loadmodule "cachedb_local.so"
loadmodule "clusterer.so"
loadmodule "db_mysql.so"
loadmodule "dialog.so"
loadmodule "dialplan.so"
loadmodule "dns_cache.so"
loadmodule "drouting.so"
loadmodule "event_route.so"
loadmodule "httpd.so"
loadmodule "maxfwd.so"
loadmodule "mi_fifo.so"
loadmodule "mi_http.so"
loadmodule "perl.so"
loadmodule "permissions.so"
loadmodule "proto_bin.so"
loadmodule "proto_udp.so"
#loadmodule "qrouting.so"
loadmodule "regex.so"
# loadmodule "registrar.so"
loadmodule "rr.so"
loadmodule "signaling.so"
loadmodule "sipmsgops.so"
loadmodule "sl.so"
loadmodule "statistics.so"
loadmodule "tm.so"
# loadmodule "usrloc.so"

Although I do include other files in /etc/opensips, none of the others
load any modules.

> Regarding your corefile issue, it is definitely uncommon, the basic 
> "opensips" + "opensips-dbg" package recipe should be enough for you
> to 
> visualize at least a backtrace out of an OpenSIPS corefile.  One
> guess 
> would be that you are also installing an "opensips" binary through
> "make 
> install" on the same box, which is not symbol-compatible with the 
> "opensips-dbg" debugging package.  Could this be the case?

No I'm pretty sure I didn't do that. If I did I would have put the
source files into /usr/src and on this machine that directory is empty.

Is there anything I can do to verify anything?

BTW, I seem to be able to make it crash by just makinging (literally) 2
or 3 phone calls.

Cheers,
Kingsley.


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

[OpenSIPS-Users] OpenSIPS crashing but gdb not recognising core dump symbols

[Kingsley Tart]

Hi,

OpenSIPS 3.1.5 is crashing a lot on Debian 10.

I'm trying to use gdp to get a trace from a core dump but it isn't
loading the symbols.

I installed opensips-dbg, restarted opensips, managed to crash it again
and then ran gdb to examine the core dump, but it still didn't have the
symbols.

Here are the installed OpenSIPS packages:

root@ipx-a:/tmp# apt list --installed | grep opensips

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

opensips-cli/buster,now 0.1~20211008~ef1f5e2-1 all [installed]
opensips-dbg/buster,now 3.1.5-1 amd64 [installed]
opensips-dialplan-module/buster,now 3.1.5-1 amd64 [installed]
opensips-http-modules/buster,now 3.1.5-1 amd64 [installed]
opensips-mysql-module/buster,now 3.1.5-1 amd64 [installed]
opensips-perl-modules/buster,now 3.1.5-1 amd64 [installed]
opensips-regex-module/buster,now 3.1.5-1 amd64 [installed]
opensips/buster,now 3.1.5-1 amd64 [installed]
root@ipx-a:/tmp#


This is what gdp said:

root@ipx-a:/tmp# gdb . core.opensips.107.1635172491.18078
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
.: Is a directory.
[New LWP 18078]
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid
-f /etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55866bba8e5b in ?? ()
(gdb) bt full
#0  0x55866bba8e5b in ?? ()
No symbol table info available.
#1  0x7fe747d6e2d0 in ?? ()
No symbol table info available.
#2  0x55866bb729d8 in ?? ()
No symbol table info available.
#3  0x7fe747bc441b in ?? ()
No symbol table info available.
#4  0x348db1ec12d63600 in ?? ()
No symbol table info available.
#5  0x0400 in ?? ()
No symbol table info available.
#6  0x7fe747bca300 in ?? ()
No symbol table info available.
#7  0x in ?? ()
No symbol table info available.
(gdb)

How can I fix this to get a proper trace?

Regards,
Kingsley.


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

[OpenSIPS-Users] failed to process sync chunk warnings when doing dr_reload

[Kingsley Tart]

Hi,

I have a 3 node cluster running OpenSIPS 3.1.5.

If for example on node 1 I do a dr reload on the command line like
this:

# opensips-cli -x mi dr_reload
"OK"
#

I suddenly see a load of warnings in opensips.log:


Oct 22 18:25:06 ipx-a /usr/sbin/opensips[312]:
INFO:drouting:dr_reload_cmd: dr_reload MI command received!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[312]:
INFO:drouting:dr_reload_data_head: loading drouting data!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[312]:
INFO:drouting:dr_reload_data_head: loading drouting data!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[312]:
INFO:clusterer:send_sync_req: Sent sync request for capability
'drouting-status-repl' to node 3, cluster 1
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[336]:
INFO:clusterer:handle_sync_packet: Received all sync packets for
capability 'drouting-status-repl' in cluster 1
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[336]:
INFO:drouting:receive_dr_cluster_event: Synchronized carriers and
gateways status from cluster
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to process sync chunk!
Oct 22 18:25:06 ipx-a /usr/sbin/opensips[342]:
WARNING:drouting:dr_recv_sync_packet: failed to 

Re: [OpenSIPS-Users] validate_dialog() failing to recognise reinvites

[Kingsley Tart]

Hi,

Thanks, that all makes perfect sense.

During the tests I had to insert another test and forgot to preserve
$rc from validate_dialog() which explains the difference between the -1
I was printing and the -2 that the function would have returned.

Thanks for the reference to the RFC. I shall present this extract to
the carrier to point out what they are doing wrong:

   -  A user, ttl, or method uri-parameter appearing in only one
  URI never matches, even if it contains the default value.

Thank you Bogdan, that's a massive help.

Cheers,
Kingsley.

On Thu, 2021-10-21 at 09:27 +0300, Bogdan-Andrei Iancu wrote:
> Hi,
> 
> So the error log is about the "remote contact", but the return code
> is -1 ?? (which according to doc [1] means invalid cseq). Checking
> the code, you should have get a -2 ret code in correlation to that
> log (see [2]).
> 
> Now, based on the error log, I see that the dialog module retained
> the "sip:asterisk@1.1.1.28:5060" URI (from a received Contact hdr),
> but it gets from the other party (as RURI) a different value, the
> "sip:asterisk@1.1.1.28:5060;user=phone" . And according to RFC3261
> [3], that extra "user" URI param makes the URI not to match anymore -
> see chapter " 9.1.4 URI Comparison"
> 
> 
> o  URI uri-parameter components are compared as follows:
> 
>  -  Any uri-parameter appearing in both URIs must match.
> 
>  -  A user, ttl, or method uri-parameter appearing in only
> one
> URI never matches, even if it contains the default value.
> 
> 
> 
> [1] 
> https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_validate_dialog
> [2] 
> https://github.com/OpenSIPS/opensips/blob/master/modules/dialog/dlg_handlers.c#L2707
> [3] https://www.ietf.org/rfc/rfc3261.txt
> 
> Regards,
> On 10/19/21 12:06 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > Thanks. I hadn't noticed before but yes, I'm seeing this:
> > 
> > ERROR:dialog:dlg_validate_dialog: failed to validate remote
> > contact: dlg=[sip:asterisk@1.1.1.28:5060] , req=[sip:
> > asterisk@1.1.1.28:5060;user=phone]
> > 
> > I can't see anywhere in the SIP trace where that contact URI
> > appears
> > *without* user=phone in it so I don't understand why that's
> > happening.
> > 
> > Cheers,
> > Kingsley.
> > 
> > On Tue, 2021-10-19 at 10:08 +0300, Bogdan-Andrei Iancu wrote:
> > > Hi Kingsley,
> > > 
> > > According to the docs [1], the "-1" ret code means "No  SIP
> > > message". Do you see any parsing errors in the logs, while doing
> > > the validation?
> > > 
> > > 
> > > [1] 
> > > https://opensips.org/html/docs/modules/3.1.x/sipmsgops.html#func_sipmsg_validate
> > > 
> > > Regards,
> > > On 10/18/21 5:25 PM, Kingsley Tart wrote:
> > > > Hi,
> > > > 
> > > > Using OpenSIPS 3.1.5 I'm getting validate_dialog() returning
> > > > $rc=-1 on
> > > > re-invites.
> > > > 
> > > > 
> > > > I have this in opensips.cfg:
> > > > 
> > > > modparam("dialog", "dlg_match_mode", 1)
> > > > 
> > > > 
> > > > The top of route() looks like this:
> > > > 
> > > > route {
> > > > if (has_totag()) {
> > > > if (is_method("ACK") && t_check_trans()) {
> > > > t_relay();
> > > > exit;
> > > > }
> > > > 
> > > > if (!loose_route()) {
> > > > send_reply(404, "Not here");
> > > > exit;
> > > > }
> > > > 
> > > > if (!validate_dialog()) {
> > > > xlog("L_WARN", "Ignoring $rm from $si
> > > > due to invalid dialog; rc=$rc\n");
> > > > }
> > > > 
> > > > 
> > > > I've attached an (anonymised) SIP trace. OpenSIPS isn't
> > > > responding to
> > > > the reinvites as I'm seeing "Ignoring INVITE from (address) due
> > > > to
> > > > invalid dialog: rc=-1" (as per the xlog above).
> > > > 
> > > > Is there something wrong with these re-invite messages, or
> > > > something
> > > > I'm doing wrong in OpenSIPS?
> > > > 
> > > > Cheers,
> > > > Kingsley.
> > > > 
> > > > 
> > > > ___
> > > > Users mailing list
> > > > Users@lists.opensips.org
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > > 
> > >  
>  


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

Re: [OpenSIPS-Users] validate_dialog() failing to recognise reinvites

[Kingsley Tart]

Hi,

Thanks. I hadn't noticed before but yes, I'm seeing this:

ERROR:dialog:dlg_validate_dialog: failed to validate remote contact: 
dlg=[sip:asterisk@1.1.1.28:5060] , req=[sip:asterisk@1.1.1.28:5060;user=phone]

I can't see anywhere in the SIP trace where that contact URI appears
*without* user=phone in it so I don't understand why that's happening.

Cheers,
Kingsley.

On Tue, 2021-10-19 at 10:08 +0300, Bogdan-Andrei Iancu wrote:
> Hi Kingsley,
> 
> According to the docs [1], the "-1" ret code means "No  SIP message". Do you 
> see any parsing errors in the logs, while doing the validation?
> 
> 
> [1] 
> https://opensips.org/html/docs/modules/3.1.x/sipmsgops.html#func_sipmsg_validate
> 
> Regards,
> On 10/18/21 5:25 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > Using OpenSIPS 3.1.5 I'm getting validate_dialog() returning $rc=-1 on
> > re-invites.
> > 
> > 
> > I have this in opensips.cfg:
> > 
> > modparam("dialog", "dlg_match_mode", 1)
> > 
> > 
> > The top of route() looks like this:
> > 
> > route {
> > if (has_totag()) {
> > if (is_method("ACK") && t_check_trans()) {
> > t_relay();
> > exit;
> > }
> > 
> > if (!loose_route()) {
> > send_reply(404, "Not here");
> > exit;
> > }
> > 
> > if (!validate_dialog()) {
> > xlog("L_WARN", "Ignoring $rm from $si due to invalid 
> > dialog; rc=$rc\n");
> > }
> > 
> > 
> > I've attached an (anonymised) SIP trace. OpenSIPS isn't responding to
> > the reinvites as I'm seeing "Ignoring INVITE from (address) due to
> > invalid dialog: rc=-1" (as per the xlog above).
> > 
> > Is there something wrong with these re-invite messages, or something
> > I'm doing wrong in OpenSIPS?
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


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

[OpenSIPS-Users] validate_dialog() failing to recognise reinvites

[Kingsley Tart]

Hi,

Using OpenSIPS 3.1.5 I'm getting validate_dialog() returning $rc=-1 on
re-invites.


I have this in opensips.cfg:

modparam("dialog", "dlg_match_mode", 1)


The top of route() looks like this:

route {
if (has_totag()) {
if (is_method("ACK") && t_check_trans()) {
t_relay();
exit;
}

if (!loose_route()) {
send_reply(404, "Not here");
exit;
}

if (!validate_dialog()) {
xlog("L_WARN", "Ignoring $rm from $si due to invalid 
dialog; rc=$rc\n");
}


I've attached an (anonymised) SIP trace. OpenSIPS isn't responding to
the reinvites as I'm seeing "Ignoring INVITE from (address) due to
invalid dialog: rc=-1" (as per the xlog above).

Is there something wrong with these re-invite messages, or something
I'm doing wrong in OpenSIPS?

Cheers,
Kingsley.
U 2021/10/18 14:15:23.943154 2.2.2.2:5060 -> 1.1.1.1:5060 #59215
INVITE sip:+44116100@1.1.1.1;user=phone SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKe056.3c6d36.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj5938cccb-0c93-4e5d-bead-6e3935d11729.
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12746 INVITE.
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE, REFER.
Supported: 100rel, timer, replaces, norefersub, histinfo.
Session-Expires: 1800.
Min-SE: 90.
Privacy: none.
X-Channel: PJSIP/custom-0016.
X-Call-Unique-Id: 1634562923.45_8.
Max-Forwards: 70.
User-Agent: Asterisk PBX GIT-master-cc127a999cM.
Content-Type: application/sdp.
Content-Length:   396.
To: .
From: 
;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
Contact: .
P-Asserted-Identity: "+44197014" .
P-Preferred-Identity: "+44197014" .
Remote-Party-ID: "+44197014" 
;privacy=off;screen=yes.
.
v=0.
o=- 1815475440 1815475440 IN IP4 1.1.1.28.
s=Asterisk.
c=IN IP4 1.1.1.28.
t=0 0.
m=audio 19038 RTP/AVP 8 0 3 9 110 117 119 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:9 G722/8000.
a

U 2021/10/18 14:15:23.952884 1.1.1.1:5060 -> 2.2.2.2:5060 #59216
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKe056.3c6d36.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj5938cccb-0c93-4e5d-bead-6e3935d11729.
From: 
;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
To: .
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12746 INVITE.
Content-Length: 0.
.

U 2021/10/18 14:15:24.087736 1.1.1.1:5060 -> 2.2.2.2:5060 #59217
SIP/2.0 180 Ringing.
Require: 100rel.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKe056.3c6d36.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj5938cccb-0c93-4e5d-bead-6e3935d11729.
RSeq: 1.
Record-Route: .
To: ;tag=3843551724-754411543.
From: 
;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12746 INVITE.
Allow: UPDATE,PRACK,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL.
Contact: .
Content-Length: 0.
.

U 2021/10/18 14:15:24.089132 2.2.2.2:5060 -> 1.1.1.1:5060 #59220
PRACK sip:+44116100@1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKf056.534775a.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj97ff6c6d-3bea-4e77-9a3d-707144abac65.
From: ;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
To: ;tag=3843551724-754411543.
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12747 PRACK.
RAck: 1 12746 INVITE.
Max-Forwards: 70.
User-Agent: Asterisk PBX GIT-master-cc127a999cM.
Content-Length:  0.
.

U 2021/10/18 14:15:24.391563 1.1.1.1:5060 -> 2.2.2.2:5060 #59223
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKf056.534775a.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj97ff6c6d-3bea-4e77-9a3d-707144abac65.
Record-Route: .
To: ;tag=3843551724-754411543.
From: 
;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12747 PRACK.
Allow: UPDATE,PRACK,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL.
Content-Length: 0.
.

U 2021/10/18 14:15:24.392177 1.1.1.1:5060 -> 2.2.2.2:5060 #59225
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKe056.3c6d36.0.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj5938cccb-0c93-4e5d-bead-6e3935d11729.
Record-Route: .
To: ;tag=3843551724-754411543.
From: 
;tag=e8ade979-2439-47b4-94c9-6e67ea31c76d.
Call-ID: 82dafe20-03a2-4007-a9d8-f9e5efa2cb4f.
CSeq: 12746 INVITE.
Allow: UPDATE,PRACK,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL.
Contact: .
Content-Length: 0.
.

U 2021/10/18 14:15:34.601395 2.2.2.2:5060 -> 1.1.1.1:5060 #59276
ACK sip:+44116100@1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKe056.3c6d36.2.
Via: SIP/2.0/UDP 
1.1.1.28:5060;received=1.1.1.28;rport=5060;branch=z9hG4bKPj957d6fcf-11a6-4d72-9995-42e2082f3dc4.
From: 

Re: [OpenSIPS-Users] SQL Query Variables

[Kingsley Tart]

On Fri, 2021-08-13 at 20:27 +0500, HS wrote:
> Hi all.
> 
> In my quest to make the push server work on my Opensips 3.0
> installation. I have figured out that the following query isn't
> working correctly:
> 
> $avp(query) = "SELECT token, app, platform, sip_instance from
> push_tokens WHERE username='" + $(var(user){s.escape.common}) + "'
> AND domain='" + $(var(domain){s.escape.common}) + "'";
> 
> When I replace $(var(user...)/$var(domain...) with $(tU..) and
> $(td..), the query seems to work. I have tried multiple combinations,
> but the original query isn't working.
> 
> What do I need to change to make the original query work? I did find
> details of what tU is, but nothing about var(user).

Does your query contain what you think it does? Do you see what you
expect if you do

xlog("Query=$avp(query)\n");

?

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] dlg_sharing_tag behaviour in an active/backup setup

[Kingsley Tart]

If you maintain the VIP with keepalived for example, then in your VIP
config for keepalived you could configure a notify_master script which
keepalived would then run when the node picks up the VIP, eg:

notify_master /path/to/script/notify-up.sh

and then in that script run something like this (assuming OpenSIPS
3.x):

opensips-cli -x mi clusterer_shtag_set_active your-tagname

which would make the node that now has the VIP set the tag active on
itself and as far as I understand it, OpenSIPS clusterer would make set
it to "backup" on other node.

Cheers,
Kingsley.


On Tue, 2021-07-13 at 14:08 +0100, solarmon wrote:
> Hi Liviu,
> 
> I took and used the 'recommended' config as advised at 
> https://blog.opensips.org/2018/03/23/clustering-ongoing-calls-with-opensips-2-4/
> 
> Having to rely on an(other) script to 'fix' the issue does not sound
> like a good idea, but I'll look into it further and try to understand
> it.
> 
> Thank you.
> 
> On Tue, 13 Jul 2021 at 12:59, Liviu Chircu 
> wrote:
> > On 25.06.2021 15:12, solarmon wrote:
> > > The typical recommended configuration for an active/standby setup
> > > would be:
> > > 
> > > node1:
> > > modparam("dialog", "dlg_sharing_tag", "vip=active")
> > > 
> > > node2:
> > > modparam("dialog", "dlg_sharing_tag", "vip=backup")
> > > 
> > > How can this be properly resolved or managed for these situations
> > > where you want to take down an opensips node for maintenance?
> > 
> > Hi,
> > Actually, I would recommend starting with "backup / backup" (!!) to
> > prevent exactly the scenario you described above, where you take
> > down the former-active node for maintenance, yet it boots in
> > "active" mode, completely opposite to the state of the VIP.
> > Now, in order to fix the state where both tags are in "backup"
> > mode, you'd deploy an external check-script that periodically scans
> > the tag statuses and fixes a "backup" tag to "active" whenever a
> > box owns the VIP.
> > Best Regards,
> > -- 
> > Liviu Chircu
> > www.twitter.com/liviuchircu | www.opensips-solutions.com
> > OpenSIPS Summit 2021 Distributed | www.opensips.org/events
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] time going backwards?

[Kingsley Tart]

Gah, thanks - I was having a mega brain fart, clearly. I even already
had this function in my config (!!) ... :-/

BTW, apologies for the lateness of my reply - I've been on holiday.

route[get_timestamp_hires] {
$var(N25_resultAVP) = $param(1);
# returns a floating point number as a string "$seconds.$decimals" 
representing the timestamp
# accurate to a millisecond. Because $Ts and $Tsm are separate variabls 
in OpenSIPS, there is
# a tiny chance that $Ts might advance to the next clock second while 
reading $Tsm, which could
# result in a reported timestamp almost exactly a second wrong.
# Therefore, here we generate a timestamp string where we mitigate 
against that possibility.

$var(N25_Ts) = $Ts;
$var(N25_Tsm) = $Tsm/1000;
if ($Ts > $var(N25_Ts)) {
# clock has advanced, take new values
$var(N25_Ts) = $Ts;
$var(N25_Tsm) = $Tsm/1000;
}
if ($var(N25_Tsm) < 10) {
$var(N25_Tsm) = "00" + $var(N25_Tsm);
} else if ($var(N25_Tsm) < 100) {
$var(N25_Tsm) = "0" + $var(N25_Tsm);
}

$avp($var(N25_resultAVP)) = "" + $var(N25_Ts) + "." + $var(N25_Tsm);
}

Cheers,
Kingsley.

On Sat, 2021-06-26 at 19:37 +0200, Gregory Massel wrote:
> Per https://www.opensips.org/Documentation/Script-CoreVar-3-1
> $Tsm - reference to current microseconds of the current second 
> This means that if the second counter cycles up, the microsecond counter will 
> cycle back to zero and you'll get a negative.
> e.g. Let's assume that at the time of the first reading of $Tsm it is 
> 12:00:00.9 and, at the time of the second reading, it's 12:00:01.3, 
> then you'll get a result of -0.6, because you're looking at the fraction 
> of a second in isolation to the second counter.
> So you probably need something like:
>   $var(t0s) = $Ts;
>   $var(t0ms) = $Tsm;
>   $var(node_number) = route(get_my_node_number);
>   $var(dur) = (($Ts - $var(t0s))*100) + $Tsm - $var(t0ms);
> 
> Note: I'm not sure whether the syntax above is correct (I've never tried to 
> do arithmetic operations within OpenSIPS), but the basic idea is there.
> --Greg
> On 2021-06-25 22:01, Kingsley Tart wrote:
> > Hi,
> > 
> > For testing, this code at the top of my route script:
> > 
> > $var(t0) = $Tsm;
> > $var(node_number) = route(get_my_node_number);
> > $var(dur) = $Tsm - $var(t0);
> > xlog("My node number is $var(node_number) and it took $var(dur) 
> > microsecconds to find out\n");
> > 
> > has just logged this:
> > 
> > Jun 25 20:55:01 [598]: My node number is -1 and it took 65 
> > microsecconds to find out
> > Jun 25 20:55:03 [598]: My node number is -1 and it took 67 
> > microsecconds to find out
> > Jun 25 20:55:05 [598]: My node number is -1 and it took 64 
> > microsecconds to find out
> > Jun 25 20:55:05 [578]: My node number is -1 and it took 602523 
> > microsecconds to find out
> > Jun 25 20:55:06 [579]: My node number is -1 and it took -79396 
> > microsecconds to find out
> > Jun 25 20:55:07 [598]: My node number is -1 and it took 63 
> > microsecconds to find out
> > Jun 25 20:55:07 [580]: My node number is -1 and it took -455503 
> > microsecconds to find out
> > Jun 25 20:55:07 [579]: My node number is -1 and it took 108 
> > microsecconds to find out
> > Jun 25 20:55:09 [598]: My node number is -1 and it took 78 
> > microsecconds to find out
> > Jun 25 20:55:11 [598]: My node number is -1 and it took 68 
> > microsecconds to find out
> > Jun 25 20:55:13 [598]: My node number is -1 and it took 66 
> > microsecconds to find out
> > Jun 25 20:55:15 [598]: My node number is -1 and it took 68 
> > microsecconds to find out
> > Jun 25 20:55:17 [598]: My node number is -1 and it took 65 
> > microsecconds to find out
> > Jun 25 20:55:18 [578]: My node number is -1 and it took 107 
> > microsecconds to find out
> > Jun 25 20:55:19 [598]: My node number is -1 and it took 71 
> > microsecconds to find out
> > 
> > which is weird because time seems to have gone backwards a couple of times.
> > 
> > Using OpenSIPS 3.1.2 in a VM running Debian 10, with the host being a
> > CentOS 7 machine running Qemu KVM.
> > 
> > Any idea what's happening here?
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] time going backwards?

[Kingsley Tart]

Hi,

For testing, this code at the top of my route script:

$var(t0) = $Tsm;
$var(node_number) = route(get_my_node_number);
$var(dur) = $Tsm - $var(t0);
xlog("My node number is $var(node_number) and it took $var(dur) 
microsecconds to find out\n");

has just logged this:

Jun 25 20:55:01 [598]: My node number is -1 and it took 65 
microsecconds to find out
Jun 25 20:55:03 [598]: My node number is -1 and it took 67 
microsecconds to find out
Jun 25 20:55:05 [598]: My node number is -1 and it took 64 
microsecconds to find out
Jun 25 20:55:05 [578]: My node number is -1 and it took 602523 
microsecconds to find out
Jun 25 20:55:06 [579]: My node number is -1 and it took -79396 
microsecconds to find out
Jun 25 20:55:07 [598]: My node number is -1 and it took 63 
microsecconds to find out
Jun 25 20:55:07 [580]: My node number is -1 and it took -455503 
microsecconds to find out
Jun 25 20:55:07 [579]: My node number is -1 and it took 108 
microsecconds to find out
Jun 25 20:55:09 [598]: My node number is -1 and it took 78 
microsecconds to find out
Jun 25 20:55:11 [598]: My node number is -1 and it took 68 
microsecconds to find out
Jun 25 20:55:13 [598]: My node number is -1 and it took 66 
microsecconds to find out
Jun 25 20:55:15 [598]: My node number is -1 and it took 68 
microsecconds to find out
Jun 25 20:55:17 [598]: My node number is -1 and it took 65 
microsecconds to find out
Jun 25 20:55:18 [578]: My node number is -1 and it took 107 
microsecconds to find out
Jun 25 20:55:19 [598]: My node number is -1 and it took 71 
microsecconds to find out

which is weird because time seems to have gone backwards a couple of times.

Using OpenSIPS 3.1.2 in a VM running Debian 10, with the host being a
CentOS 7 machine running Qemu KVM.

Any idea what's happening here?

Cheers,
Kingsley.


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

[OpenSIPS-Users] Dialog replication weirdness

[Kingsley Tart]

Hi,

I'm not sure whether this is a bug (OpenSIPS 3.1.2). I'm trying to do
dialog clustering with the dialog module.

Before clustering, I had this in the module settings:

modparam("dialog", "profiles_with_value", "RX; TX")

And I read the sizes in a timer route with this:

get_profile_size("RX", $var(NXX_endpoint), $var(NXX_RX));
get_profile_size("TX", $var(NXX_endpoint), $var(NXX_TX));

Which works.


Now with clustering. The clusterer is set up, and the cachedb_local
module is successfully using it. So I change the dialog parameter to
this:

modparam("dialog", "profiles_with_value", "RX/s; TX/s")

but dialogs weren't replicating, though no errors in opensips.log. So I
tried this instead:

modparam("dialog", "profiles_with_value", "RX/b; TX/b")

and suddenly my timer route generates these errors:

ERROR:dialog:w_get_profile_size: profile  not defined
ERROR:dialog:w_get_profile_size: profile  not defined

until I edit it to say this:

get_profile_size("RX/b", $var(NXX_endpoint), $var(NXX_RX));
get_profile_size("TX/b", $var(NXX_endpoint), $var(NXX_TX));


So why do I need to add "/b" when I use the /b flag, but not add "/s"
when I use the /s flag?


Oh wait ... a few restarts later and now it's complaining 

ERROR:dialog:w_get_profile_size: profile  not defined
ERROR:dialog:w_get_profile_size: profile  not defined

but if I edit my timer route again to remove /b the errors stop but
it's not getting the sizes any more, but I now get errors when the
routing script tries to add dialogs to the profile, so I remove /b from
set_dlg_profile() and now the errors have stopped, but the dialogs have
stopped replicating ... ??

This is too much weirdness for one day. Time for beer.

Cheers,
Kingsley.


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

[OpenSIPS-Users] dialog only written to DB for answered calls

[Kingsley Tart]

Hi,

I have the dialog module set to do delayed DB updates every 2 seconds,
but dialogs don't get written to the DB unless a call is answered.
However, "opensips-cli -x mi dlg_list" shows dialogs where the remote
end is still ringing.


I have these settings for the dialog module:

loadmodule "dialog.so"
modparam("dialog", "db_url", "mysql://opensips:BLAH@BLAH/opensips")
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_update_period", 2)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "options_ping_interval", 30)


Is it possible to get the dialog module to write ALL dialogs into the
DB, not just ones where the call has been answered?

This is OpenSIPS 3.1.2.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] null dialog error on callee BYE

[Kingsley Tart]

Aha! Thank you - that was it.

I was re-writing the host in the Contact header because I had
misunderstood the requirements from one of our carriers. Commenting out
the block of OpenSIPS code that did that fixed it.

Thank you once again :)

Cheers,
Kingsley.

On Fri, 2021-06-11 at 10:05 +0300, Răzvan Crainea wrote:
> Hi, Kingsley!
> 
> The BYE that comes from gw1 does not appear to be right, as the r-uri 
> domain points to OpenSIPS itself, therefore, after the first 
> loose_route(), the BYE would loop back to OpenSIPS - that's probably 
> when you get that error.
> The BYE coming from gw1 should have gw2 in R-URI (79.121.42.22:5060), 
> not the proxy's IP. This is probably happening due to a bad contact sent 
> to gw1, or perhaps a bad fixing of the contact of gw1 - I don't have the 
> entire call flow, so I can't say exactly.
> What you could try though is after validate_dialog(), run 
> fix_route_dialog() [1] - this might repair what gw1 is sending and point 
> R-URI to gw2.
> 
> [1] https://opensips.org/docs/modules/3.2.x/dialog.html#idp6271744
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 6/10/21 8:24 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > I'm getting null dialog errors when the callee hangs up, but not when
> > the caller hangs up.
> > 
> > In this example, I'm calling from gw2 to gw1. The call gets answered.
> > If gw2 hangs up, all is good. If gw1 hangs up, it is not.
> > 
> > This is the top of my routing script (xlog just for diags):
> > 
> > if (has_totag()) {
> > if (is_method("ACK") && t_check_trans()) {
> > t_relay();
> > exit;
> > }
> > if (!loose_route()) {
> > xlog("NOT loose_route()\n");
> > send_reply(404, "Not here");
> > exit;
> > } else {
> > xlog("loose_route() OK\n");
> > }
> > if (!validate_dialog()) {
> > xlog("Ignoring $rm from $si due to invalid dialog; rc=$rc\n");
> > exit;
> > }
> > if (is_method("BYE")) {
> > route(acc_leg_set_end_reason);
> > }
> > route(relay);
> > exit;
> > }
> > 
> > 
> > And this is the dialog match mode:
> > 
> > modparam("dialog", "dlg_match_mode", 1)
> > 
> > I'm calling record_route() and then create_dialog("pP") when I receive
> > an INVITE.
> > 
> > 
> > If the call is answered and then gw1 sends the BYE, I get this in the
> > opensips log:
> > 
> > loose_route() OK
> > ERROR:dialog:w_validate_dialog: null dialog
> > Ignoring BYE from 79.121.42.21 due to invalid dialog; rc=-4
> > 
> > 
> > and I see the following SIP messages coming from gw1, and re-trying
> > because I'm dropping the messages due to null dialog:
> > 
> > (RX and TX from the perspective of OpenSIPS)
> > 
> > RX<-gw1  U 2021/06/10 17:58:44.950661 79.121.42.21:5060 -> 
> > 79.121.42.45:5060 #29059
> > RX<-gw1  BYE sip:asterisk@79.121.42.45:5060 SIP/2.0.
> > RX<-gw1  Via: SIP/2.0/UDP 
> > 79.121.42.21:5060;rport;branch=z9hG4bKPjc946d0af-e97d-4f85-b592-58df46d73d0e.
> > RX<-gw1  From: 
> > ;tag=0b7b5a28-2dc1-493f-8d74-c939674643f3.
> > RX<-gw1  To: 
> > ;tag=682e4380-74c8-4a53-a1f4-a339d758c986.
> > RX<-gw1  Call-ID: cc4f4b92-7ba0-4c43-9b8e-c467fa897460.
> > RX<-gw1  CSeq: 30163 BYE.
> > RX<-gw1  Route: .
> > RX<-gw1  Reason: Q.850;cause=16.
> > RX<-gw1  Max-Forwards: 70.
> > RX<-gw1  User-Agent: Asterisk PBX 13.27.0.
> > RX<-gw1  Content-Length:  0.
> > RX<-gw1  .
> > 
> > RX<-gw1  U 2021/06/10 17:58:45.451242 79.121.42.21:5060 -> 
> > 79.121.42.45:5060 #29060
> > RX<-gw1  BYE sip:asterisk@79.121.42.45:5060 SIP/2.0.
> > RX<-gw1  Via: SIP/2.0/UDP 
> > 79.121.42.21:5060;rport;branch=z9hG4bKPjc946d0af-e97d-4f85-b592-58df46d73d0e.
> > RX<-gw1  From: 
> > ;tag=0b7b5a28-2dc1-493f-8d74-c939674643f3.
> > RX<-gw1  To: 
> > ;tag=682e4380-74c8-4a53-a1f4-a339d758c986.
> > RX<-gw1  Call-ID: cc4f4b92-7ba0-4c43-9b8e-c467fa897460.
> > RX<-gw1  CSeq: 30163 BYE.
> > RX<-gw1  Route: .
> > RX<-gw1  Reason: Q.850;cause=16.
> > RX<-gw1  Max-Forwards: 70.
> > RX<-gw1  User-Agent: Asterisk PBX 13.27.0.
> > RX<-gw1  Content-Length:  0.
> > RX<-gw1  .
> > 
> > RX<-gw1 

[OpenSIPS-Users] null dialog error on callee BYE

[Kingsley Tart]

Hi,

I'm getting null dialog errors when the callee hangs up, but not when
the caller hangs up.

In this example, I'm calling from gw2 to gw1. The call gets answered.
If gw2 hangs up, all is good. If gw1 hangs up, it is not.

This is the top of my routing script (xlog just for diags):

if (has_totag()) {
if (is_method("ACK") && t_check_trans()) {
t_relay();
exit;
}
if (!loose_route()) {
xlog("NOT loose_route()\n");
send_reply(404, "Not here");
exit;
} else {
xlog("loose_route() OK\n");
}
if (!validate_dialog()) {
xlog("Ignoring $rm from $si due to invalid dialog; rc=$rc\n");
exit;
}
if (is_method("BYE")) {
route(acc_leg_set_end_reason);
}
route(relay);
exit;
}


And this is the dialog match mode:

modparam("dialog", "dlg_match_mode", 1)

I'm calling record_route() and then create_dialog("pP") when I receive
an INVITE.


If the call is answered and then gw1 sends the BYE, I get this in the
opensips log:

loose_route() OK
ERROR:dialog:w_validate_dialog: null dialog
Ignoring BYE from 79.121.42.21 due to invalid dialog; rc=-4


and I see the following SIP messages coming from gw1, and re-trying
because I'm dropping the messages due to null dialog:

(RX and TX from the perspective of OpenSIPS)

RX<-gw1  U 2021/06/10 17:58:44.950661 79.121.42.21:5060 -> 79.121.42.45:5060 
#29059
RX<-gw1  BYE sip:asterisk@79.121.42.45:5060 SIP/2.0.
RX<-gw1  Via: SIP/2.0/UDP 
79.121.42.21:5060;rport;branch=z9hG4bKPjc946d0af-e97d-4f85-b592-58df46d73d0e.
RX<-gw1  From: 
;tag=0b7b5a28-2dc1-493f-8d74-c939674643f3.
RX<-gw1  To: 
;tag=682e4380-74c8-4a53-a1f4-a339d758c986.
RX<-gw1  Call-ID: cc4f4b92-7ba0-4c43-9b8e-c467fa897460.
RX<-gw1  CSeq: 30163 BYE.
RX<-gw1  Route: .
RX<-gw1  Reason: Q.850;cause=16.
RX<-gw1  Max-Forwards: 70.
RX<-gw1  User-Agent: Asterisk PBX 13.27.0.
RX<-gw1  Content-Length:  0.
RX<-gw1  .

RX<-gw1  U 2021/06/10 17:58:45.451242 79.121.42.21:5060 -> 79.121.42.45:5060 
#29060
RX<-gw1  BYE sip:asterisk@79.121.42.45:5060 SIP/2.0.
RX<-gw1  Via: SIP/2.0/UDP 
79.121.42.21:5060;rport;branch=z9hG4bKPjc946d0af-e97d-4f85-b592-58df46d73d0e.
RX<-gw1  From: 
;tag=0b7b5a28-2dc1-493f-8d74-c939674643f3.
RX<-gw1  To: 
;tag=682e4380-74c8-4a53-a1f4-a339d758c986.
RX<-gw1  Call-ID: cc4f4b92-7ba0-4c43-9b8e-c467fa897460.
RX<-gw1  CSeq: 30163 BYE.
RX<-gw1  Route: .
RX<-gw1  Reason: Q.850;cause=16.
RX<-gw1  Max-Forwards: 70.
RX<-gw1  User-Agent: Asterisk PBX 13.27.0.
RX<-gw1  Content-Length:  0.
RX<-gw1  .

RX<-gw1  U 2021/06/10 17:58:46.450860 79.121.42.21:5060 -> 79.121.42.45:5060 
#29061
RX<-gw1  BYE sip:asterisk@79.121.42.45:5060 SIP/2.0.
RX<-gw1  Via: SIP/2.0/UDP 
79.121.42.21:5060;rport;branch=z9hG4bKPjc946d0af-e97d-4f85-b592-58df46d73d0e.
RX<-gw1  From: 
;tag=0b7b5a28-2dc1-493f-8d74-c939674643f3.
RX<-gw1  To: 
;tag=682e4380-74c8-4a53-a1f4-a339d758c986.
RX<-gw1  Call-ID: cc4f4b92-7ba0-4c43-9b8e-c467fa897460.
RX<-gw1  CSeq: 30163 BYE.
RX<-gw1  Route: .
RX<-gw1  Reason: Q.850;cause=16.
RX<-gw1  Max-Forwards: 70.
RX<-gw1  User-Agent: Asterisk PBX 13.27.0.
RX<-gw1  Content-Length:  0.
RX<-gw1  .


but if the caller (gw2) hangs up and sends the BYE, then all is fine:

RX<-gw2  U 2021/06/10 17:57:37.506889 79.121.42.22:5060 -> 79.121.42.45:5060 
#29043
RX<-gw2  BYE sip:79.121.42.21:5060 SIP/2.0.
RX<-gw2  Via: SIP/2.0/UDP 
79.121.42.22:5060;rport;branch=z9hG4bKPjdf132a9c-ee20-4cbd-bbf4-ccb3d0aaab42.
RX<-gw2  From: 
;tag=c91f69bc-9548-4245-86b9-a9202d0b33c8.
RX<-gw2  To: 
;tag=3d0cfd81-357b-448f-92ab-712aadfdf895.
RX<-gw2  Call-ID: 38e1a3aa-54d3-456a-99b2-201295179c95.
RX<-gw2  CSeq: 9118 BYE.
RX<-gw2  Route: .
RX<-gw2  Reason: Q.850;cause=16.
RX<-gw2  Max-Forwards: 70.
RX<-gw2  User-Agent: Asterisk PBX 13.27.0.
RX<-gw2  Content-Length:  0.
RX<-gw2  .

TX->gw1  U 2021/06/10 17:57:37.507451 79.121.42.45:5060 -> 79.121.42.21:5060 
#29044
TX->gw1  BYE sip:79.121.42.21:5060 SIP/2.0.
TX->gw1  Via: SIP/2.0/UDP 79.121.42.45:5060;branch=z9hG4bK5071.80e2e516.0.
TX->gw1  Via: SIP/2.0/UDP 
79.121.42.22:5060;received=79.121.42.22;rport=5060;branch=z9hG4bKPjdf132a9c-ee20-4cbd-bbf4-ccb3d0aaab42.
TX->gw1  From: 
;tag=c91f69bc-9548-4245-86b9-a9202d0b33c8.
TX->gw1  To: 
;tag=3d0cfd81-357b-448f-92ab-712aadfdf895.
TX->gw1  Call-ID: 38e1a3aa-54d3-456a-99b2-201295179c95.
TX->gw1  CSeq: 9118 BYE.
TX->gw1  Reason: Q.850;cause=16.
TX->gw1  Max-Forwards: 70.
TX->gw1  User-Agent: Asterisk PBX 13.27.0.
TX->gw1  Content-Length:  0.
TX->gw1  .

RX<-gw1  U 2021/06/10 17:57:37.508346 79.121.42.21:5060 -> 79.121.42.45:5060 
#29045
RX<-gw1  SIP/2.0 200 OK.
RX<-gw1  Via: SIP/2.0/UDP 
79.121.42.45:5060;rport=5060;received=79.121.42.45;branch=z9hG4bK5071.80e2e516.0.
RX<-gw1  Via: SIP/2.0/UDP 
79.121.42.22:5060;rport=5060;received=79.121.42.22;branch=z9hG4bKPjdf132a9c-ee20-4cbd-bbf4-ccb3d0aaab42.
RX<-gw1  Call-ID: 

Re: [OpenSIPS-Users] multi ip address with diffrent reply options

[Kingsley Tart]

Hi,

I don't know - I have never used the dispacher module.

Cheers,
Kingsley.

On Mon, 2021-06-07 at 14:38 +0300, gataka wrote:
> Dear  Kingsley , 
> It can work if you talking about the options geting to you,
> what about sending the options from you
> in the cfg I set 
> modparam("dispatcher", "ds_ping_from", "sip:ping@PUBLIC_IP_1")
> but I have PUBLIC_IP_X for different proposals.
> 
> thanks
> 
> 
> 
> 
> On Mon, Jun 7, 2021 at 12:52 PM Kingsley Tart  wrote:
> > Yes I do this by setting t_on_reply("OPTIONS") when the request comes
> > in and then create a route onreply_route[OPTIONS] that changes the
> > headers in the response using remove_hf() and append_hf().
> > 
> > If you want to handle the options request locally you could use
> > append_to_reply() to append the additional headers to your reply.
> > 
> > Note: I'm quite new to OpenSIPS so there may be a better way.
> > 
> > Cheers,
> > Kingsley.
> > 
> > On Mon, 2021-06-07 at 12:13 +0300, Erez wrote:
> > > Hey ,
> > > I create a container with multi ip address , 
> > > now I need to reply to the options with different ip addresses ,but
> > > all the options go from one interface with one ip address in the
> > > options header
> > > Is it possible to rewrite options param on the fly ?
> > > 
> > > thanks in advance
> > > Gataka
> > > ___
> > > Users mailing list
> > > Users@lists.opensips.org
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] multi ip address with diffrent reply options

[Kingsley Tart]

Yes I do this by setting t_on_reply("OPTIONS") when the request comes
in and then create a route onreply_route[OPTIONS] that changes the
headers in the response using remove_hf() and append_hf().

If you want to handle the options request locally you could use
append_to_reply() to append the additional headers to your reply.

Note: I'm quite new to OpenSIPS so there may be a better way.

Cheers,
Kingsley.

On Mon, 2021-06-07 at 12:13 +0300, Erez wrote:
> Hey ,
> I create a container with multi ip address , 
> now I need to reply to the options with different ip addresses ,but
> all the options go from one interface with one ip address in the
> options header
> Is it possible to rewrite options param on the fly ?
> 
> thanks in advance
> Gataka
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] reactor size

[Kingsley Tart]

Hi,

What difference does reactor size make? How do I know what size I need?

I'm getting the below warnings in the log. While I can see what the
warning tells me to make it go away, I don't know what effect this will
have:

WARNING:core:init_reactor_size: shrinking reactor size from 262144
(autodetected via rlimit) to 10485 (limited by memory of 10% from 4Mb)
WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other
limit or increase pkg memory

This is currently running on a VM with just 1GB RAM allocated to it.
I'm not sure how to calculate whether this is enough.


Cheers,
Kingsley.


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

[OpenSIPS-Users] coding style / {param.exists, name} and {param.value, name}

[Kingsley Tart]

Hi,

Is one of these methods specifically preferred over another? The first
seems more explicit, but seems to me that OpenSIPS would have to parse
the param list twice - once to check whether the param exists and then
again to get the value. Is the second method acceptable?


Method 1:

if ($(var(pstring){param.exists,customparam})) {
$var(pval) = $(var(pstring){param.value,customparam});
# do other stuff
}


Method 2:

$var(pval) = $(var(pstring){param.value,customparam});
if ($var(pval) != NULL {
# do other stuff
}


There is a functional difference between them that in method 1, if the
param doesn't exist then $var(pval) doesn't get set (it might already
exist with a different value), but if this didn't matter in the context
of the code, is one way preferred over the other?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli

[Kingsley Tart]

Hi,

I don't have a separate opensips-cli.cfg file on my system and I've
never written one so I wouldn't know whether there's anything wrong
with yours. In /etc/opensips there is just this:

# ls -l
total 36
-rw-r--r-- 1 root root 27561 May 18 15:53 opensips.cfg
-rw-r--r-- 1 root root  3751 Mar  2 17:26 opensipsctlrc
-rw-r--r-- 1 root root   353 Nov 17 13:45 scenario_callcenter.xml

Nothing special in opensips.cfg. I only added the partition stuff
recently but I was getting the dr_* commands listed before as well:

loadmodule "drouting.so"
modparam("drouting", "db_url", "mysql://opensips:@localhost/opensips")
modparam("drouting", "probing_interval", 15)
modparam("drouting", "use_partitions", 1)
modparam("drouting", "db_partitions_url", 
"mysql://opensips:@localhost/opensips")
modparam("drouting", "db_partitions_table", "dr_partitions")

Does opensips-cli.cfg need to have a DB module listed as well? Is it
listing commands from other modules that require a DB module?

Cheers,
Kingsley.

On Tue, 2021-05-18 at 15:52 +0100, John Quick wrote:
> How curious. I wonder what is different about your config and mine.
> Here is my opensips-cli.cfg. Can you see anything wrong please?
> Or perhaps it is linked to the opensips.cfg script - I load the
> drouting module, but might not actually call any of the functions
> 
> [default]
> log_level: WARNING
> prompt_intro: Hello mate
> prompt_name: osipscli-local
> database_url: mysql://opensips:@localhost
> database_name: opensips_v3
> database_modules: acc alias_db auth_db avpops domain dialog drouting
> group permissions clusterer rtpproxy rtpengine tls_mgm usrloc
> registrant tracer fraud_detection freeswitch_scripting
> 
> John Quick
> Smartvox Limited
> 
> 
> -Original Message-
> From: Kingsley Tart  
> Sent: 18 May 2021 15:47
> To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list' <
> users@lists.opensips.org>
> Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips-
> cli
> 
> Interesting. When I do it (with OpenSIPS 3.1.2), I get the below,
> with the dr_* commands listed:
> 
> # opensips-cli -x mi which
> [
> "get_statistics",
> "list_statistics",
> "reset_statistics",
> "uptime",
> "version",
> "pwd",
> "arg",
> "which",
> "ps",
> "kill",
> "log_level",
> "xlog_level",
> "shm_check",
> "cache_store",
> "cache_fetch",
> "cache_remove",
> "event_subscribe",
> "events_list",
> "subscribers_list",
> "raise_event",
> "list_tcp_conns",
> "mem_pkg_dump",
> "mem_shm_dump",
> "mem_rpm_dump",
> "reload_routes",
> "help",
> "list_blacklists",
> "t_uac_dlg",
> "t_uac_cancel",
> "t_hash",
> "t_reply",
> "dlg_list",
> "dlg_list_ctx",
> "dlg_end_dlg",
> "dlg_db_sync",
> "dlg_restore_db",
> "dlg_cluster_sync",
> "profile_get_size",
> "profile_list_dlgs",
> "profile_get_values",
> "list_all_profiles",
> "profile_end_dlgs",
> "dlg_push_var",
> "dlg_send_sequential",
> "address_reload",
> "address_dump",
> "subnet_dump",
> "allow_uri",
> "dr_reload",
> "dr_gw_status",
> "dr_carrier_status",
> "dr_number_routing",
> "dr_reload_status",
> "dr_enable_probing",
> "dp_reload",
> "dp_translate",
> "dp_show_partition",
> "cache_remove_chunk",
> "regex_reload"
> ]
> 
> Cheers,
> Kingsley.
> 
> On Tue, 2021-05-18 at 15:43 +0100, John Quick wrote:
> > Unfortunately no.
> > It just re-iterates the list that I was already looking at where I 
> > could not find any commands for the drouting module or to do the
> > other 
> > operations I reported as missing.
> > 
> > John Quick
> > Smartvox Limited
> > 
> > 
> > -Original Message-
> > From: Kingsley Tart 
> > Sent: 18 May 2021 15:38
> > To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list < 
> > users@lists.opensips.org>
> > Subject: Re: [OpenSIPS-Users] Some mi commands missing in
> > opensips- 
> > cli
> > 
> > Does "opensips-cli -x mi which" do what you want?
> > 
> > Cheers,
> > Kingsley.
> > 
> 
> 


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

Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli

[Kingsley Tart]

I know that feeling ;)

Cheers,
Kingsley.

On Tue, 2021-05-18 at 15:59 +0100, John Quick wrote:
> Damn. I was sure I’d loaded the drouting module, but now I checked
> and find I haven’t. Doh!
> Juggling too many scripts in my head.


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

Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli

[Kingsley Tart]

Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, with
the dr_* commands listed:

# opensips-cli -x mi which
[
"get_statistics",
"list_statistics",
"reset_statistics",
"uptime",
"version",
"pwd",
"arg",
"which",
"ps",
"kill",
"log_level",
"xlog_level",
"shm_check",
"cache_store",
"cache_fetch",
"cache_remove",
"event_subscribe",
"events_list",
"subscribers_list",
"raise_event",
"list_tcp_conns",
"mem_pkg_dump",
"mem_shm_dump",
"mem_rpm_dump",
"reload_routes",
"help",
"list_blacklists",
"t_uac_dlg",
"t_uac_cancel",
"t_hash",
"t_reply",
"dlg_list",
"dlg_list_ctx",
"dlg_end_dlg",
"dlg_db_sync",
"dlg_restore_db",
"dlg_cluster_sync",
"profile_get_size",
"profile_list_dlgs",
"profile_get_values",
"list_all_profiles",
"profile_end_dlgs",
"dlg_push_var",
"dlg_send_sequential",
"address_reload",
"address_dump",
"subnet_dump",
"allow_uri",
"dr_reload",
"dr_gw_status",
"dr_carrier_status",
"dr_number_routing",
"dr_reload_status",
"dr_enable_probing",
"dp_reload",
"dp_translate",
"dp_show_partition",
"cache_remove_chunk",
"regex_reload"
]

Cheers,
Kingsley.

On Tue, 2021-05-18 at 15:43 +0100, John Quick wrote:
> Unfortunately no.
> It just re-iterates the list that I was already looking at where I
> could not find any commands for the drouting module or to do the
> other operations I reported as missing.
> 
> John Quick
> Smartvox Limited
> 
> 
> -Original Message-
> From: Kingsley Tart  
> Sent: 18 May 2021 15:38
> To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list <
> users@lists.opensips.org>
> Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips-
> cli
> 
> Does "opensips-cli -x mi which" do what you want?
> 
> Cheers,
> Kingsley.
> 


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

Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli

[Kingsley Tart]

Does "opensips-cli -x mi which" do what you want?

Cheers,
Kingsley.

On Tue, 2021-05-18 at 15:20 +0100, John Quick wrote:
> The mi commands for the drouting module are not appearing in the list of
> allowed mi commands in opensips-cli.
> I'm looking for things like dr_reload, dr_gw_status, etc.
> 
> Some of the commands that were available in opensipsctl, I am struggling to
> find the equivalent available in opensips-cli:
>  "show" commands for address, domain, db etc.  Now there is only "dump"
>  Commands to manipulate or show the data used in the alias_db module
>  Commands to add data to domain, drouting, address
> 
> Are these now done using the database command in the cli? If so, please
> could someone post a few examples as I don't get the command format or help.
> 
> Just a reminder - I posted to this forum on 5th May that
> "opensips-cli>database create" crashes if the username given in
> opensips-cli.cfg is anything other than opensips
> Not had any response. Do I need to post somewhere else?
> 
> John Quick
> Smartvox Limited
> 
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] opposite of {s.int} ?

[Kingsley Tart]

Wow that worked, thanks. So I guess the first value sets the type,
whereupon it's OK to append an integer to a string, but not OK to add a
string to an integer ...

Cheers,
Kingsley.

On Thu, 2021-05-13 at 16:24 -0400, Ovidiu Sas wrote:
> Try the other way around:
> $dlg_val(dstSeq) = "" + $var(tmp);
> 
> -ovidiu
> 


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

[OpenSIPS-Users] opposite of {s.int} ?

[Kingsley Tart]

Hi.

Is there a transformation or something else that can convert an integer
to a string? ie do the opposite of {s.int} ?

I wanted to maintain a leg sequence number (with multi-leg accounting)
with a dialog variable, but dialog variables can only contain strings.

So I did

  $dlg_val(dstSeq) = "1";

at the start. But in the failure route for next endpoint, I wanted to
do this:

  $var(tmp) = $(dlg_val(dstSeq){s.int}) + 1;
  $dlg_val(dstSeq) = $var(tmp);

but it doesn't like assigning an integer, so I tried

  $dlg_val(dstSeq) = "$var(tmp)";

but that then assigned that literal string to the dialog variable. So
then I tried

  $dlg_val(dstSeq) = $var(tmp) + "";

but that complained about type mismatching, so in the end O had to do

  $avp(tmp) = $var(tmp);
  $dlg_val(dstSeq) = $avp(tmp);
  $avp(tmp) = NULL;

which feels messy.



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

Re: [OpenSIPS-Users] best way to do "foreach"

[Kingsley Tart]

On Wed, 2021-05-12 at 13:46 +0300, Liviu Chircu wrote:
> On 12.05.2021 13:32, Kingsley Tart wrote:
> >  $var(valindex) = $var(valindex) + 1;
> 
> Also worth mentioning that since 3.1, this statement can be re-
> written as:
> 
>   $var(valindex) += 1;

Oh excellent.

> Additionally, during your iteration, you may also take advantage of
> the fact that "$(var(valCSV){csv.param,$var(valindex)})" returns NULL
> on "index out of bounds".  Many other "indexable" transformations
> behave like this as well.

Handy to know, thanks :)

> There is actually a "foreach" statement available, applicable to any 
> variable that can be indexed [1], so maybe you could write some cleaner 
> code using that, depending on your available inputs.
> [1]: https://www.opensips.org/Documentation/Script-Statements-3-2#toc4

Thanks. The reason for actually counting the loop for the AVP version
was that it's possible (depending on where this function was called
from) that there might already be an AVP with the same name.
Specifically counting through the loop ensures I only remove the values
I put on, thus leaving it in its original state when the function
returns.

> As far as performance is concerned, the differences are negligible.  As 
> long as you follow the rule of "$var is always faster than $avp", you 
> should be writing nearly optimal script code.

I do that where I can.

> Ultimately, the bottlenecks will forever be DNS queries, SQL queries, 
> HTTP queries, TCP I/O, SIP retransmission timers, etc., with scripting 
> technique being near the bottom of the optimization priority list...

To help with that, I'm using cachedb_local with cache_store() and
cache_fetch(), populating some things in a timer route, and also using
dns_cache, so hopefully avoiding as many of those bottlenecks as is
reasonably possible to do.

Thanks for your help.

-- 
Cheers,
Kingsley.


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

[OpenSIPS-Users] best way to do "foreach"

[Kingsley Tart]

Is there a recommended way to implement a foreach loop with the
iterator iterating over a list of known values? 


For string values that won't themselves contain a comma, I could do
this:

$var(valCSV) = "string1,string2,string3,string4";
$var(valcount) = $(var(valCSV){csv.count});
$var(valindex) = 0;

while ($var($valindex) < $var($valcount)) {
$var(thisval) = $(var(valCSV){csv.param,$var(valindex)});
$var(valindex) = $var(valindex) + 1;
# more code
}


or I could use an AVP (also handy if the strings might contain a
comma):


$avp(vals) = "string4";
$avp(vals) = "string3";
$avp(vals) = "string2";
$avp(vals) = "string1";
$var(valcount) = 4;

$var(valindex) = 0;

while ($var($valindex) < $var($valcount)) {
$var(thisval) = $avp(vals);
$avp(vals) = NULL;
$var(valindex) = $var(valindex) + 1;
# more code
}

(specifically using an iterator to count through the loop in case
something else is already using that AVP - only want to delete what I
added in the first place).


Is there a perferred way, or better way than these?

Cheers,
Kingsley.


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

[OpenSIPS-Users] [SOLVED] Re: dialog end reason in CDRs

[Kingsley Tart]

On Tue, 2021-05-11 at 13:20 +0100, Kingsley Tart wrote:
> Hi,
> 
> Is there a version of this that works in OpenSIPS 3.1?
> 
> modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason")
> 
> I want to log the dialog end reason in the CDRs.

Mailer sent message while I was still typing it :-/


This logs the end reason if OpenSIPS sends the BYEs (eg dialog
timeouts):

local_route {
if (is_method("BYE")) {
$acc_extra(end_reason) = $DLG_end_reason;
}
}

This does it for normal BYEs in the main routing function:



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

[OpenSIPS-Users] [SOLVED] Re: dialog end reason in CDRs

[Kingsley Tart]

On Tue, 2021-05-11 at 13:20 +0100, Kingsley Tart wrote:
> Hi,
> 
> Is there a version of this that works in OpenSIPS 3.1?
> 
> modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason")
> 
> I want to log the dialog end reason in the CDRs.

Sorry, managed to figure this one out by doing these things:





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

[OpenSIPS-Users] dialog end reason in CDRs

[Kingsley Tart]

Hi,

Is there a version of this that works in OpenSIPS 3.1?

modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason")

I want to log the dialog end reason in the CDRs.

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields

[Kingsley Tart]

On Tue, 2021-05-11 at 12:00 +0300, Liviu Chircu wrote:
> On 11.05.2021 11:58, Kingsley Tart wrote:
> > 2. the acc module defaults these fields to NULL instead of an empty
> > string
> 
> I think defaulting to SQL's special DEFAULT value is even better.

Yes that works for me, and should do the same as not specifying the
field at all which was my first suggestion, but is probably easier for
you to implement. It's better than setting to NULL I agree.

> The discussion is already ongoing on the tracker, see [1]
> 
> [1]: https://github.com/OpenSIPS/opensips/issues/2205

Excellent. This would be a good step forward.

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields

[Kingsley Tart]

On Mon, 2021-05-10 at 19:25 +0300, Liviu Chircu wrote:
> On 10.05.2021 19:19, Kingsley Tart wrote:
> > I could do, but I was hoping to avoid that as it feels like bad
> > practice and it's inefficient - more of a workaround than a proper fix.
> 
> Speaking for myself, I don't think I've ever seen a non-VARCHAR custom 
> accounting column with the "acc" module.

I think this is probably the reason ;)

If it's the only way to make it work, people are doing it that way
because they have to.

> Also, if you think about it, 
> writing the 1 integer value requires only 25% of the space if you're 
> writing "1" instead of 1.  So, YMMV with regards to efficiency, we're 
> talking bits and pieces of data here, as the fields themselves are not 
> that large, it's their sheer number required in the CDRs that's often 
> problematic.

It depends on what you want to do to that column afterwards - see
Aron's message for example.

SQL databases have different datatypes for a reason. It would be nice
if the acc module could play nicer with that. Two possible solutions to
this are:

1. the acc module not try to set any fields where the value has not
been set in the routing script, or

2. the acc module defaults these fields to NULL instead of an empty
string

I prefer option 1 if given the choice.

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields

[Kingsley Tart]

I could do, but I was hoping to avoid that as it feels like bad
practice and it's inefficient - more of a workaround than a proper fix.

I was really hoping that OpenSIPS would simply not define fields in the
query if the value had not been specified. It seems to do as I wish if
I don't use multi-leg accounting.

Cheers,
Kingsley.

On Mon, 2021-05-10 at 19:15 +0300, Liviu Chircu wrote:
> On 10.05.2021 18:33, Kingsley Tart wrote:
> > I tried setting the fields to NULL in the routing script, and then
> > when
> > that didn't make any difference I tried setting them to 0. That
> > didn't
> > help either.
> 
> Why not just convert all custom (extra, leg) accounting columns to 
> VARCHAR(64) or VARCHAR(128), for example?  While most SQL databases 
> auto-convert integer types to strings, the opposite is _not_ true,
> hence 
> all of the errors you've been running into.
> 
> Best,
> 


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

Re: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields

[Kingsley Tart]

Hi.

I tried setting the fields to NULL in the routing script, and then when
that didn't make any difference I tried setting them to 0. That didn't
help either.

I'll have to look over what I did to see if I can reproduce the issue I
was having.

Cheers,
Kingsley.

On Mon, 2021-05-10 at 10:31 +0300, Răzvan Crainea wrote:
> Hi, Kingsley!
> 
> No, this is not a bug, it's exactly as it has been developped [1].
> 
> [1] https://opensips.org/docs/modules/3.1.x/acc.html#overview:  If a 
> value is not present in the request, the empty string is accounted
> instead.
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 


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

Re: [OpenSIPS-Users] routing function variable scope

[Kingsley Tart]

Hi Ben,

Thanks for that - yes you're right, that is exactly what is happening.

It plays nicer if I use an AVP so I'll have to use that.

Thanks once again :)

Cheers,
Kingsley.

On Fri, 2021-05-07 at 17:32 +, Ben Newlin wrote:
> Kingsley,
>  
> I think the issue here is the nested variable name references. I
> think within route csv_filter, you are actually setting a variable
> called “$var(N11_resultvar_name)”, not a variable with the name of
> the contents of that variable.
>  
> I believe you can easily confirm this with two things:
> Remove (or ignore) the parameter providing the variable name and
> hardcode it to “N9_hdrval” in csv_filter for a test. You should see
> the variable is now set when printed after.
> and/or
> Add another log after csv_filter that prints the contents of
> $var($var(N11_resultvar_name)). I think you will find it also
> contains the correct value.
>  
>  
> Ben Newlin

[snip]


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

Re: [OpenSIPS-Users] routing function variable scope

[Kingsley Tart]

Hi John,

I'm not offended at all, don't worry.

Personally I think it's counter-intuitive for a function to change
things outside of its scope. For example you wouldn't expect a call to
dp_translate() to change any of your own variables, apart from the AVP
into which you've told it to put the result.

I don't see how having locally scoped variables reduces readability but
as you note it does allow code re-use, which can be very useful.

Rookie programmers shouldn't be going anywhere near my OpenSIPS scripts
:) But they need to learn how to better program, and having a language
that can behave like many other popular ones is not something I see as
confusing for a learner.

Cheers,
Kingsley.

On Sun, 2021-05-09 at 18:20 +0100, John Quick wrote:
> Kingsley,
> 
> I hope you won't be offended, but in my opinion you are at risk of
> sacrificing code readability in the pursuit of code re-usability.
> If you accept that variables are in-scope both within the route and the
> sub-route, then why not just have one variable for the result - set it
> inside the sub-route and read the result from it immediately after the
> sub-route has returned. This may not be quite right for a code style
> perfectionist, but at least it would be easily understood by the rooky
> programmer who has to maintain your code in 5 years' time.
> 
> John Quick
> Smartvox Limited
> 
> 


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

Re: [OpenSIPS-Users] routing function variable scope

[Kingsley Tart]

On Wed, 2021-04-28 at 15:27 +0300, Liviu Chircu wrote:
> On 28.04.2021 15:19, Kingsley Tart wrote:
> > Is there a better way, apart from trying to make sure that
> > variables in
> > each function don't share names with variables in other functions?
> 
> No, you have to manage those iterator names and make sure the logic 
> still holds during nested calls.

Hi,

I have now ran into the opposite problem! Given that values seem to be
globally shared, I am now trying to use a sub-function to set the value
of a $var() variable from a parent function, but the changed value gets
lost when the sub function quits.

Here is the code:

route[bhah] {
xlog("ALLOW BEFORE=\"$var(N9_hdrval)\"\n");
route(csv_filter, $var(N9_hdrval), "(?i)^ 
*(OPTIONS|INVITE|ACK|BYE|CANCEL|UPDATE|PRACK|MESSAGE) *$", "N9_hdrval");
xlog("ALLOW AFTER=\"$var(N9_hdrval)\"\n");
}


route[csv_filter] {
$var(N11_srcCSV) = $param(1);
$var(N11_filter_regex) = $param(2);
$var(N11_resultvar_name) = $param(3);

$var(N11_result) = "";
$var(N11_pos) = $(var(N11_srcCSV){csv.count}) - 1;
while ($var(N11_pos) >= 0) {
$var(N11_element) = $(var(N11_srcCSV){csv.value,$var(N11_pos)});
if (pcre_match($var(N11_element), $var(N11_filter_regex))) {
$var(N11_result) = $var(N11_element) + "," + 
$var(N11_result);
}
$var(N11_pos) = $var(N11_pos) - 1;
}
$var(N11_resultLen) = $(var(N11_result){s.len}) - 1;
$var($var(N11_resultvar_name)) = 
$(var(N11_result){s.substr,0,$var(N11_resultLen)});
xlog("FILTERED 
var($var(N11_resultvar_name))=\"$var($var(N11_resultvar_name))\"\n");
}


But this is what gets logged:

opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, 
ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE"
opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE"
opensips[21955]: ALLOW AFTER="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, 
BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE"


This is what I was hoping to get:

opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, 
ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE"
opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE"
opensips[21955]: ALLOW AFTER="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, 
MESSAGE"


Have I done something silly here?

Cheers,
Kingsley.


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

[OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields

[Kingsley Tart]

Hi,

This is with OpenSIPS 3.1.

I have extra DB fields defined with "extra_fields", and this was
working fine until I tried to turn on multi-leg accounting so that I
could log details of failures, eg endpoint address, SIP response etc.

I have a failure route set up to try the next endpoint, eg when I get
an INVITE:

t_on_failure("next_host");

and:

failure_route[next_host] {
# dialog flag 1 means a CANCEL has been received
if (!is_dlg_flag_set(1)) {
$avp(endpoint) = NULL;
if ($avp(endpoint)) {
t_on_failure("next_host");
acc_new_leg();
sethost($avp(endpoint));
route(numheaders_set_for_endpoint);
route(relay);
exit;
}
send_reply(503, "Service unavailable");
exit;
}
}


The problems started when I added acc_new_leg() into the failure route.
I've set this up so that the first few endpoints fail so that I can see
what is happening.

The problem is that when the BYE is received, I get the following
errors:

CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1366): 
Incorrect integer value: '' for column `opensips`.`acc`.`t_ringing` at row 1
ERROR:core:db_do_insert: error while submitting query
ERROR:acc:acc_db_request: failed to insert into acc table

The problem here is that t_ringing is an integer column (which defaults
to NULL) so it can't take a string, and OpenSIPS is trying to set the
value to an empty string.

I tried specifically setting $acc_extra(t_ringing) = NULL but this made
no difference.

I tried moving t_ringing into "leg_fields" (needed to do that anyway)
and then setting $acc_leg(t_ringing) in the script when needed, but the
same problem persisted.

These are the DB actions that OpenSIPS performs on the acc and
missed_calls tables:

Prepare  insert into missed_calls 
(method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created
 ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Execute insert into missed_calls 
(method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created
 ) values 
('INVITE','2007660754','z9hG4bK048.2ac41536.0','1619701113-752375-609080253','401','Unauthorized',TIMESTAMP'2021-04-29
 
13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','00353999',NULL,NULL,'1619701113',NULL,NULL,NULL,'1619701113','88.151.41.23',0,TIMESTAMP'2021-04-29
 13:58:33')

Prepare insert into acc 
(method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration
 ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Execute insert into acc 
(method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration
 ) values 
('INVITE','2007660754',NULL,'1619701113-752375-609080253','503','Service 
Unavailable',TIMESTAMP'2021-04-29 
13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','00353999',NULL,NULL,'1619701113',NULL,NULL,NULL,'1619701113','88.151.41.23',0,NULL,0,0)

Query insert into acc 
(method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration
 ) values 
('INVITE','2007660754','','1619701113-752375-609080253','503','Service 
Unavailable','2021-04-29 
13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','00353999','','','1619701113','','','','1619701113','88.151.41.24',0,NULL,0,0)

Is this a bug?

I would prefer any fields not set in my script to be either set as
NULL, or perhaps even better not even mentione in the query at all.


-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] routing function variable scope

[Kingsley Tart]

On Wed, 2021-04-28 at 15:27 +0300, Liviu Chircu wrote:
> On 28.04.2021 15:19, Kingsley Tart wrote:
> > Is there a better way, apart from trying to make sure that variables in
> > each function don't share names with variables in other functions?
> 
> No, you have to manage those iterator names and make sure the logic 
> still holds during nested calls.

Right OK. Is it a reasonable feature request to have a variable type
called $local that is only visible within the scope that created it? Or
at least, not outside of the function, so you could use $local(myname)
just like you would use $var(myname). Other functions could then share
the same name and it would be their own local copy.

If you think that's reasonable then I'll submit it.

I'm not sure how much work it would be to implement, however!

-- 
Cheers,
Kingsley.


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

[OpenSIPS-Users] routing function variable scope

[Kingsley Tart]

Hi,

(sorry!)

Is there a way in routing functions to create variables local to just
that function?

I had a problem earlier where I had a function call another, and they
both used the same var name (intending them to be local to the
function), but the sub-function ended up overwriting the value of the
same-named var in the calling function.

I find myself using AVPs and then unsetting them afterwards in order to
not tread on vars that other functions might use but with all of the
tidyup code things get messy.

Foe example, this would loop forever, but using an AVP as the counter
variable would then need another loop to remove all of the added values
(but not all values in that AVP, in case that deletes AVPs set
somewhere else):

route(test_outer);

route[test_outer] {
$var(counter) = 0;
while ($var(counter) < 10) {
route(show_multiples, $var(counter));
$var(counter) = $var(counter) + 1;
}
}

route[show_multiples] {
$var(counter) = 1;
while ($var(counter) < 5) {
$var(multiple) = $param(1) * $var(counter);
xlog("multiple=$var(multiple)\n");
$var(counter) = $var(counter) + 1;
}
}

Is there a better way, apart from trying to make sure that variables in
each function don't share names with variables in other functions?

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] a comma ending a parameter list string?

[Kingsley Tart]

Thanks. I actually wondered about that behaviour after I sent my
initial email, tested it and found that it did that, but it's good to
know that it's deliberate behaviour.

Sorry to spam the list, I'm getting quite embarrassed about all of my
emails :(

Cheers,
Kingsley.

On Tue, 2021-04-27 at 16:15 +0300, Liviu Chircu wrote:
> On 27.04.2021 15:42, Kingsley Tart wrote:
> > $var(paramstr) =
> > "h=BT1;dir=in;dprulesRX=1,2,3;dprulesTX=4,100";
> > xlog("PARAMSTR='$var(paramstr)'\n");
> > xlog("PARAMCOUNT='$(var(paramstr){param.count})'\n");
> > ...
> > 
> > Is this deliberate behaviour? OpenSIPS 3.1, FWIW.
> 
> Hi,
> 
> Yes, that is RFC 3261 behavior.  You are not allowed to put "," in 
> either a SIP URI parameter name or its value.
> 
> However, since you have invoked this part of the RFC:
> 
> "A string of text is parsed as a single word if it is quoted using
> double-quote marks.  In quoted strings, quotation marks (") and
> backslashes (\) need to be escaped."
> 
> ... OpenSIPS kindly obliges and parses the entire parameter value,
> with 
> whatever content it may have.
> 
> Regards,
> 


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

Re: [OpenSIPS-Users] a comma ending a parameter list string?

[Kingsley Tart]

BTW, I noticed it's OK if I wrap double quotes around the CSV, eg:

$var(paramstr) = "h=BT1;dir=in;dprulesRX=\"1,2,3\";dprulesTX=\"4,100\"";

(getting a bit embarrassed with the number of emails I'm submitting to
this list, sorry).

Cheers,
Kingsley.

On Tue, 2021-04-27 at 13:42 +0100, Kingsley Tart wrote:
> Hi,
> 
> firstly apologies if this is a dumb question; I'm still pretty new to
> OpenSIPS and some aspects of SIP itself.
> 
> Is a comma supposed to mark the end of a parameter list?
> 
> Eg, if I do this, the param transformation is treating the first
> comma
> as the end of the string:
> 
>   $var(paramstr) =
> "h=BT1;dir=in;dprulesRX=1,2,3;dprulesTX=4,100";
>   xlog("PARAMSTR='$var(paramstr)'\n");
>   xlog("PARAMCOUNT='$(var(paramstr){param.count})'\n");
> 
>   xlog("h='$(var(paramstr){param.value,h})'\n");
>   xlog("dir='$(var(paramstr){param.value,dir})'\n");
>   xlog("dprulesRX='$(var(paramstr){param.value,dprulesRX})'\n");
>   xlog("dprulesTX='$(var(paramstr){param.value,dprulesTX})'\n");
> 
> then this is what gets logged:
> 
>   PARAMSTR='h=BT1;dir=in;dprulesRX=1,2,3;dprulesTX=4,100'
>   PARAMCOUNT='3'
>   h='BT1'
>   dir='in'
>   dprulesRX='1'
>   dprulesTX=''
> 
> Is this deliberate behaviour? OpenSIPS 3.1, FWIW.
> 


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

[OpenSIPS-Users] a comma ending a parameter list string?

[Kingsley Tart]

Hi,

firstly apologies if this is a dumb question; I'm still pretty new to
OpenSIPS and some aspects of SIP itself.

Is a comma supposed to mark the end of a parameter list?

Eg, if I do this, the param transformation is treating the first comma
as the end of the string:

$var(paramstr) = "h=BT1;dir=in;dprulesRX=1,2,3;dprulesTX=4,100";
xlog("PARAMSTR='$var(paramstr)'\n");
xlog("PARAMCOUNT='$(var(paramstr){param.count})'\n");

xlog("h='$(var(paramstr){param.value,h})'\n");
xlog("dir='$(var(paramstr){param.value,dir})'\n");
xlog("dprulesRX='$(var(paramstr){param.value,dprulesRX})'\n");
xlog("dprulesTX='$(var(paramstr){param.value,dprulesTX})'\n");

then this is what gets logged:

PARAMSTR='h=BT1;dir=in;dprulesRX=1,2,3;dprulesTX=4,100'
PARAMCOUNT='3'
h='BT1'
dir='in'
dprulesRX='1'
dprulesTX=''

Is this deliberate behaviour? OpenSIPS 3.1, FWIW.

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] xlog - whether to \n

[Kingsley Tart]

OK, thanks. It was working without it but I've added \n to my xlog
lines now.

Cheers,
Kingsley.

On Tue, 2021-04-27 at 14:00 +0300, Bogdan-Andrei Iancu wrote:
> The '\n' at the end of the xlog lines is a must.
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS Bootcamp 2021 online
>https://opensips.org/training/OpenSIPS_eBootcamp_2021/
> 
> On 4/27/21 1:24 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > If I use xlog() to log a single line, it does what I expect even if
> > I
> > don't end the log string with \n, so what is the reason I see
> > people
> > putting \n at the end of xlog strings?
> > 
> 
> 


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

[OpenSIPS-Users] xlog - whether to \n

[Kingsley Tart]

Hi,

If I use xlog() to log a single line, it does what I expect even if I
don't end the log string with \n, so what is the reason I see people
putting \n at the end of xlog strings?

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] redirect an already-established call to another host?

[Kingsley Tart]

Thank you Bogdan. Will look at that :)

Cheers,
Kingsley.

On Fri, 2021-04-23 at 14:58 +0300, Bogdan-Andrei Iancu wrote:
> Hi,
> 
> An established call cannot be redirect, but it can be transferred to 
> another SIP endpoint. See the SIP attended and unattended (blind)
> transfer.
> 
> Regards,
> 
> Bogdan-Andrei Iancu



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

[OpenSIPS-Users] redirect an already-established call to another host?

[Kingsley Tart]

Hi,

Is it possible to redirect a call to another endpoint if the call and
media path has already been established?

We have a number of Asterisk boxes and have OpenSIPS forwarding calls
to these using load balancing logic.

One of the services these Asterisk boxes perform is conference calls,
so all callers to a particular conference need to go to the same
Asterisk box.

The issue is that we cannot determine the conference by the number
called. The user calls, gets connected to Asterisk and then uses DTMF
to enter a conference number. It is only then that we know which
conference it is.

Currently, the Asterisk box then has to check a central database to see
whether that conference has any other participants and if so which
Asterisk box is hosting it. If on a different box, Asterisk has to make
a SIP call to the box where the conference is, so the user's call is
going through two Asterisk boxes by this point.

It would be nice if there was a clean way for the Asterisk box to tell
OpenSIPS which asterisk box to go to, and then have OpenSIPS forward
the call there instead.

Is this possible?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] dialplan module - ensuring a substring exists in URI

[Kingsley Tart]

Hi,

Thanks but I tried that and whatever I tried I could not get it to
work. I don't know whether I have misunderstood what you meant?


With this setup:
+--++--++-+-+-+
| dpid | pr | match_op | match_exp  | match_flags | subst_exp   | repl_exp  
  |
+--++--++-+-+-+
|  100 |  1 |1 | (;user=phone)? |   1 | ;user=phone | 
;user=phone |
+--++--++-+-+-+

I got this:

# opensips-cli -x mi dp_reload
"OK"
# opensips-cli -x mi dp_translate 100 "+12...@sip.com;food=beans"
ERROR: command 'dp_translate' returned: 404: No translation
# opensips-cli -x mi dp_translate 100 "+12...@sip.com;user=phone"
{
"Output": ";user=phone",
"ATTRIBUTES": ""
}


and with this setup:

+--++--++-++-+
| dpid | pr | match_op | match_exp  | match_flags | subst_exp  | 
repl_exp|
+--++--++-++-+
|  100 |  1 |1 | (;user=phone)? |   1 | (;user=phone)? | 
;user=phone |
+--++--++-++-+

I got this:

# opensips-cli -x mi dp_reload
"OK"
# opensips-cli -x mi dp_translate 100 "+12...@sip.com;food=beans"
{
"Output": ";user=phone",
"ATTRIBUTES": ""
}
# opensips-cli -x mi dp_translate 100 "+12...@sip.com;user=phone"
{
"Output": ";user=phone",
"ATTRIBUTES": ""
}

but also realised that if it had matched, I would have no control over
where in the URI it would have added the extra text, so I'm wondering
that my two rule approach is perhaps the best way for what I'm doing
anyway.

Cheers,
Kingsley.

On Wed, 2021-04-21 at 12:47 +0300, Bogdan-Andrei Iancu wrote:
> Hi Kingsley,
> 
> You could try with a single rule, like optional matching the param (like 
> "(;user=phone)?") and in subst + repl part do not include the param 
> inside the \1 parenthesis, having it added all the time in the repl part.
> 
> Still you need a more complex matching if you have multiple params, not 
> only the "user" one.
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS Bootcamp 2021 online
>https://opensips.org/training/OpenSIPS_eBootcamp_2021/
> 
> On 4/20/21 8:16 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > I want a DP ruleset to ensure that ";user=phone" is in the SIP URI,
> > ie
> > if it is not there, add it, but if it is already there, do nothing.
> > 
> > I've managed to do this with two lines, but is there a more
> > efficient
> > way?
> > 
> > This is what I have in the dialplan table in this ruleset?
> > 
> > ++--+-+-+---+
> > ---+
> > > pr | match_op | match_exp   | match_flags | subst_exp |
> > > repl_exp  |
> > 
> > ++--+-+-+---+
> > ---+
> > >  1 |1 | ;user=phone |   1 | (.+)  |
> > > \1|
> > >  2 |1 | .   |   1 | (.+)  |
> > > \1;user=phone |
> > 
> > ++--+-+-+---+
> > ---+
> > 
> 
> 


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

Re: [OpenSIPS-Users] dialplan module - dpid - could it be a string?

[Kingsley Tart]

I've added it as a feature request:

https://github.com/OpenSIPS/opensips/issues/2477

Cheers,
Kingsley.

On Wed, 2021-04-21 at 10:58 +0300, Bogdan-Andrei Iancu wrote:
> Indeed, it may be an interesting one. And as Ben said, we are also
> using M4 for the scripting, nevertheless, if you want to integrate
> with OpenSIPS Control Panel, it may become tricky ;)
> 
> Regards,
> On 4/20/21 9:05 PM, Ben Newlin wrote:
> > This sounds like it might be a good feature request [1] and I agree
> > it sounds nice. I can’t offer any assistance in that direction at
> > this time, but I wanted to say that we use M4 in our config scripts
> > to allow us to define string constants like this and make the
> > script more readable, among other reasons. Could be a good short-
> > term workaround. We specifically use it to define string-based
> > dialplan IDs for use in the script, just like this.
> >  
> > [1] 
> > https://github.com/OpenSIPS/opensips/issues/new?assignees===feature_request.md=%5BFEATURE%5D
> >  
> > Ben Newlin
> >  
> > From: Users  on behalf of
> > Kingsley Tart 
> > Date: Tuesday, April 20, 2021 at 12:22 PM
> > To: OpenSIPS users mailling list 
> > Subject: [OpenSIPS-Users] dialplan module - dpid - could it be a
> > string?
> > 
> > I love the dialplan module and how the rules can be reloaded from a
> > DB.
> > 
> > However, is there any reason why the dpid can't be a string instead
> > of
> > an integer? (ie the value that's stored in the dialplan.dpid
> > field).
> > 
> > I think it would be handy to be able to apply names to dialplan
> > rulesets as it would be more intuitive. If dpid could be a string,
> > then
> > I could for example create a ruleset that I could refer to as
> > "uk_local_to_e164" instead of "7".
> > 
> > Could this be a thing?
> > 
> > -- 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > 
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] dialplan module - ensuring a substring exists in URI

[Kingsley Tart]

Hi,

I want a DP ruleset to ensure that ";user=phone" is in the SIP URI, ie
if it is not there, add it, but if it is already there, do nothing.

I've managed to do this with two lines, but is there a more efficient
way?

This is what I have in the dialplan table in this ruleset?

++--+-+-+---+---+
| pr | match_op | match_exp   | match_flags | subst_exp | repl_exp  |
++--+-+-+---+---+
|  1 |1 | ;user=phone |   1 | (.+)  | \1|
|  2 |1 | .   |   1 | (.+)  | \1;user=phone |
++--+-+-+---+---+

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] Generate CANCEL on 180

[Kingsley Tart]

Firstly, I'm new to OpenSIPS so treat my comments accordingly.

But, can you do something in an onreply route?

eg, in a test setup I have, when I get an INVITE I do this:

create_dialog("pPB");
t_on_reply("doodle");

(I can't remember whether the dialog is needed for this)

and then I have this:

onreply_route[doodle] {
# expect $T_reply_code to likely first be 100
# then 180 or 183 for a progressing call
# 200 when call is answered
# or failure code (eg 4xx) or whatever
if (t_check_status("^1[0-9][0-9]$")) {
switch ($T_reply_code) {
case 180: $acc_extra(t_ringing) = $Ts; break;
case 183: $acc_extra(t_progress) = $Ts; break;
}
} else if (t_check_status("^2[0-9][0-9]$")) {
$acc_extra(t_answer) = $Ts;
} else {
xlog("Something else\n");
}
}

so when a 180 is received, it calls the above route function. Could you
send a CANCEL from there?

Cheers,
Kingsley.

On Tue, 2021-04-20 at 16:55 +0300, Antonis Psaras wrote:
> Dear all
> 
> I am trying to create a service which will generate missed calls. In
> order to be more accurate, I want to CANCEL the request when 180 is
> received.
> 
> The scenario is the following
> 
> Asterisk Invite -> OpenSIPs -> Carrier
> 
> Carrier 183 -> OpenSIPs -> Asterisk
> 
> Carrier 180 -> OpenSIPs
> 
> OpenSIPs Cancel -> Carrier
> 
>  
> Is that possible to be done from script without external app?
>  
> Regards
>  
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] dialplan module - dpid - could it be a string?

[Kingsley Tart]

I love the dialplan module and how the rules can be reloaded from a DB.

However, is there any reason why the dpid can't be a string instead of
an integer? (ie the value that's stored in the dialplan.dpid field).

I think it would be handy to be able to apply names to dialplan
rulesets as it would be more intuitive. If dpid could be a string, then
I could for example create a ruleset that I could refer to as
"uk_local_to_e164" instead of "7".

Could this be a thing?

-- 
Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] Matching dialog IDs

[Kingsley Tart]

Here you go:

https://github.com/OpenSIPS/opensips/issues/2463

Cheers,
Kingsley.

On Fri, 2021-04-09 at 14:01 +0300, Răzvan Crainea wrote:
> Hi, Kingsley!
> 
> Just open an issue on OpenSIPS github page[1], it would be easier for us 
> to keep track of them. You will find the procedure there.
> I think the feature is to also provide the dialog id in the event.
> 
> [1] https://github.com/OpenSIPS/opensips/issues
> 
> Thanks,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 4/9/21 1:58 PM, Kingsley Tart wrote:
> > What would you like me to specifically request, and how do I submit a
> > feature request for OpenSIPS?
> > 
> > Cheers,
> > Kingsley.
> > 
> > On Fri, 2021-04-09 at 11:01 +0300, Răzvan Crainea wrote:
> > > Hi, Kingsley!
> > > 
> > > I am afraid your approach is the correct one, and currently there's no
> > > other workaround, rather than the one you already did :(.
> > > Last year I've reworked the did and dlg_id in a few places to have a
> > > more consistent value, but somehow I missed the event's one. Ideally, we
> > > should have only two formats: the hex one (the one in Record-Route,
> > > dlg_list and $DLG_did), and the db_id one (the integer in DB).
> > > I will try to rework this in the master branch, any chance you could
> > > open a feature request for it?
> > > 
> > > Best regards,
> > > 
> > > Răzvan Crainea
> > > OpenSIPS Core Developer
> > > http://www.opensips-solutions.com
> > > 
> > > On 4/9/21 2:04 AM, Kingsley Tart wrote:
> > > > Hi,
> > > > 
> > > > With OpenSIPS 3.1, on one example call I noted that:
> > > > 
> > > >* did in Record-Route header was 5af.b5c82a2
> > > >* dlg_id in DB table was 17201388227675
> > > >* event_route[E_DLG_STATE_CHANGED] got hash_entry=4005 (param 1) and
> > > >  hash_id=44207195 (param 2)
> > > > 
> > > > I see these 3 sets of values are all essentially the same thing but in
> > > > a different format.
> > > > 
> > > > In a way it feels wrong to ask this but, is this guaranteed behaviour?
> > > > 
> > > > 
> > > > eg in the event route, this expression:
> > > > 
> > > > $(param(1){s.dec2hex}{s.reverse}{s.tolower}) + "." +
> > > > $(param(2){s.dec2hex}{s.reverse}{s.tolower});
> > > > 
> > > > evaluates to "5af.b5c82a2", ie the did in the Record-Route header, and
> > > > that in MySQL I could derive the dlg_id value in the DB table (which
> > > > was 17201388227675) by doing *POW(2,32)+YYY where  is the
> > > > value of $param(1) and YYY is the value of $param(2).
> > > > 
> > > > There may be a better way to do all this, but I'm trying to figure out
> > > > ways I can update the DB with some additional info at BYE time and
> > > > haven't currently found out how to do this more properly.
> > > > 
> > > > (again, this feels the wrong way to do it, but I have not yet found a
> > > > better way).
> > > > 
> > > > Cheers,
> > > > Kingsley.
> > > > 
> > > > 


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

Re: [OpenSIPS-Users] OpenSIPS 3.1 DB logging INVITEs but not BYEs

[Kingsley Tart]

Hi,

I found that changing this:

  modparam("acc", "early_media", 1)

to this:

  modparam("acc", "early_media", 0)

Has stopped the multiple records. With early_media on, a 180 or 183
created a new record.

I already have that info in custom fields anyway by having this (just
testing, so "doodle" was as good a name as any at the time :) ):

onreply_route[doodle] {
if (t_check_status("^1[0-9][0-9]$")) {
switch ($T_reply_code) {
case 180: $acc_extra(t_ringing) = $Ts; break;
case 183: $acc_extra(t_progress) = $Ts; break;
}
} else if (t_check_status("^2[0-9][0-9]$")) {
$acc_extra(t_answer) = $Ts;
} else {
$acc_extra(t_clear) = $Ts;
}
}

though the t_clear field only gets logged for missed calls, not
answered ones (but the call duration for answered calls IS logged in
the duration field, so I suppose t_clear is superfluous in the acc
table, really). I tried putting the setting of $acc_extra(t_clear) into
event_route[E_DLG_STATE_CHANGED] when new state=5 but this didn't work
either. 

I don't actually mind not getting the BYE logged specifically as long
as I can tell when it happened (as I can from the duration field). It's
just that I was following an example in Bogdan's book about OpenSIPS
2.1 that seemed to expect a BYE to be logged separately.

Cheers,
Kingsley.

On Fri, 2021-04-09 at 14:10 +0300, Răzvan Crainea wrote:
> Hi, Marcin, Kingsley!
> 
> Indeed, if you'll be running only do_accounting("db", "cdr"), you will 
> only get one record, at the end of the call, containing the `INVITE` 
> method. That's more or less hardcoded there, and can't be changed. 
> Giving a second thought about it, I somehow agree that's not 100% 
> suggestive or correct, although I was the one who wrote that code :).
> The idea was to create a CDR format compatible with previous formats of 
> acc, which were requiring a method. But since a call consists of several 
> methods, the easiest way to pick one was to pick the first one, namely 
> INVITE. Hence the CDR always has an INVITE method.
> If you have other thoughts on this, any feedback is welcome.
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 4/8/21 8:26 PM, Marcin Groszek wrote:
> > At initial invite some information are stored like a start time, this is 
> > needed to calculate the duration at the call end.
> > 
> > I believe if you do: do_accounting("db","cdr") this will write only 1 
> > invite entry in acc at the end of the call,
> > 
> > but if you do: do_accounting("db") this will write your invite and bye 
> > as 2 entries in acc table.
> > 
> > make a call, select * from acc at your db hung up the call and select 
> > again you will see when the entries are written.
> > 
> > You may also use ngrep -port 3306 -dlo to monitor db access by opensips 
> > but you have to change localhost to 127.0.0.1 in modparam.
> > 
> > modparam("acc", "db_url", "mysql://opensips:opensipsrw@127.0.0.1/opensips")
> > 
> > 
> > 
> > On 4/8/2021 11:09 AM, Kingsley Tart wrote:
> > > I would prefer a single record as well. I don't understand why using
> > > the dialog module makes it write a new "INVITE" record at BYE time
> > > instead of either writing a BYE record, or allowing me to update it
> > > with a few custom fields, one of which would be t_end or something.
> > > 
> > > Cheers,
> > > Kingsley.
> > > 
> > > On Thu, 2021-04-08 at 09:17 -0500, Marcin Groszek wrote:
> > > > Because you are using dialog that invite entry in acc table is
> > > > written at the time of bye.
> > > > I prefer a single entry in acc table for each call, not 2
> > > > 
> > > > Best regards:
> > > > Marcin Groszek
> > > > 
> > > > > On Apr 8, 2021, at 8:15 AM, Kingsley Tart 
> > > > > wrote:
> > > > > 
> > > > > Thanks, though that didn't seem to have made any difference :(
> > > > > 
> > > > > It *is* logging durations though (something you mentioned in your
> > > > > other
> > > > > email).
> > > > > 
> > > > > Cheers,
> > > > > Kingsley.
> > > 
> > > ___
> > > Users mailing list
> > > Users@lists.opensips.org
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > > 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

Re: [OpenSIPS-Users] OpenSIPS 3.1 DB logging INVITEs but not BYEs

[Kingsley Tart]

Hi,

I don't know whether you know but MariaDB v10 (that's the version I
happen to be using; I don't know about other versions or specifically
MySQL) has a general log that can be enabled and if on, logs all
queries, thus avoiding the need to use ngrep; eg:

MariaDB [opensips]> SHOW VARIABLES LIKE '%general%';
+--++
| Variable_name| Value  |
+--++
| general_log  | OFF|
| general_log_file | bt-ipx-proxy-b.log |
+--++
2 rows in set (0.001 sec)

MariaDB [opensips]> SET @@GLOBAL.general_log=1;
Query OK, 0 rows affected (0.012 sec)

MariaDB [opensips]> SHOW VARIABLES LIKE '%general%';
+--++
| Variable_name| Value  |
+--++
| general_log  | ON |
| general_log_file | bt-ipx-proxy-b.log |
+--++
2 rows in set (0.002 sec)

MariaDB [opensips]> exit
Bye

# cat /var/lib/mysql/bt-ipx-proxy-b.log
/usr/sbin/mysqld, Version: 10.3.27-MariaDB-0+deb10u1 (Debian 10). started with:
Tcp port: 3306  Unix socket: /run/mysqld/mysqld.sock
TimeId Command  Argument
210409 12:34:59 334515 QuerySHOW VARIABLES LIKE '%general%'
210409 12:36:35 334515 Quit

(ie it logged my querying of the variables the second time now that the
setting was enabled).

Obviously it's not something you'd want to leave enabled for long in
some environments :)

Cheers,
Kingsley.

On Thu, 2021-04-08 at 12:26 -0500, Marcin Groszek wrote:
> At initial invite some information are stored like a start time, this is 
> needed to calculate the duration at the call end.
> 
> I believe if you do: do_accounting("db","cdr") this will write only 1 
> invite entry in acc at the end of the call,
> 
> but if you do: do_accounting("db") this will write your invite and bye 
> as 2 entries in acc table.
> 
> make a call, select * from acc at your db hung up the call and select 
> again you will see when the entries are written.
> 
> You may also use ngrep -port 3306 -dlo to monitor db access by opensips 
> but you have to change localhost to 127.0.0.1 in modparam.
> 
> modparam("acc", "db_url", "mysql://opensips:opensipsrw@127.0.0.1/opensips")



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

Re: [OpenSIPS-Users] Matching dialog IDs

[Kingsley Tart]

What would you like me to specifically request, and how do I submit a
feature request for OpenSIPS?

Cheers,
Kingsley.

On Fri, 2021-04-09 at 11:01 +0300, Răzvan Crainea wrote:
> Hi, Kingsley!
> 
> I am afraid your approach is the correct one, and currently there's no 
> other workaround, rather than the one you already did :(.
> Last year I've reworked the did and dlg_id in a few places to have a 
> more consistent value, but somehow I missed the event's one. Ideally, we 
> should have only two formats: the hex one (the one in Record-Route, 
> dlg_list and $DLG_did), and the db_id one (the integer in DB).
> I will try to rework this in the master branch, any chance you could 
> open a feature request for it?
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 4/9/21 2:04 AM, Kingsley Tart wrote:
> > Hi,
> > 
> > With OpenSIPS 3.1, on one example call I noted that:
> > 
> >   * did in Record-Route header was 5af.b5c82a2
> >   * dlg_id in DB table was 17201388227675
> >   * event_route[E_DLG_STATE_CHANGED] got hash_entry=4005 (param 1) and
> > hash_id=44207195 (param 2)
> > 
> > I see these 3 sets of values are all essentially the same thing but in
> > a different format.
> > 
> > In a way it feels wrong to ask this but, is this guaranteed behaviour?
> > 
> > 
> > eg in the event route, this expression:
> > 
> > $(param(1){s.dec2hex}{s.reverse}{s.tolower}) + "." +
> > $(param(2){s.dec2hex}{s.reverse}{s.tolower});
> > 
> > evaluates to "5af.b5c82a2", ie the did in the Record-Route header, and
> > that in MySQL I could derive the dlg_id value in the DB table (which
> > was 17201388227675) by doing *POW(2,32)+YYY where  is the
> > value of $param(1) and YYY is the value of $param(2).
> > 
> > There may be a better way to do all this, but I'm trying to figure out
> > ways I can update the DB with some additional info at BYE time and
> > haven't currently found out how to do this more properly.
> > 
> > (again, this feels the wrong way to do it, but I have not yet found a
> > better way).
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


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

[OpenSIPS-Users] Matching dialog IDs

[Kingsley Tart]

Hi,

With OpenSIPS 3.1, on one example call I noted that:

 * did in Record-Route header was 5af.b5c82a2
 * dlg_id in DB table was 17201388227675
 * event_route[E_DLG_STATE_CHANGED] got hash_entry=4005 (param 1) and
   hash_id=44207195 (param 2)

I see these 3 sets of values are all essentially the same thing but in
a different format.

In a way it feels wrong to ask this but, is this guaranteed behaviour?


eg in the event route, this expression:

$(param(1){s.dec2hex}{s.reverse}{s.tolower}) + "." +
$(param(2){s.dec2hex}{s.reverse}{s.tolower});

evaluates to "5af.b5c82a2", ie the did in the Record-Route header, and
that in MySQL I could derive the dlg_id value in the DB table (which
was 17201388227675) by doing *POW(2,32)+YYY where  is the
value of $param(1) and YYY is the value of $param(2).

There may be a better way to do all this, but I'm trying to figure out
ways I can update the DB with some additional info at BYE time and
haven't currently found out how to do this more properly.

(again, this feels the wrong way to do it, but I have not yet found a
better way).

Cheers,
Kingsley.


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

[OpenSIPS-Users] Matching dialog IDs

[Kingsley Tart]

Hi,

With OpenSIPS 3.1, on one example call I noted that:

 * did in Record-Route header was 5af.b5c82a2
 * dlg_id in DB table was 17201388227675
 * event_route[E_DLG_STATE_CHANGED] got hash_entry=4005 (param 1) and
   hash_id=44207195 (param 2)

I see these 3 sets of values are all essentially the same thing but in
a different format.

Is this guaranteed behaviour?



eg in the event route, this expression:

$(param(1){s.dec2hex}{s.reverse}{s.tolower}) + "." + 
$(param(2){s.dec2hex}{s.reverse}{s.tolower});

evaluates to "5af.b5c82a2", ie the did in the Record-Route header, and
that in MySQL I could derive the dlg_id value in the DB table (which
was 17201388227675) by doing *POW(2,32)+YYY where  is the
value of $param(1) and YYY is the value of $param(2).

There may be a better way to do all this, but I'm trying to figure out
ways I can update the DB with some additional info at BYE time and
haven't currently found out how to do this more properly.

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS 3.1 DB logging INVITEs but not BYEs

[Kingsley Tart]

I would prefer a single record as well. I don't understand why using
the dialog module makes it write a new "INVITE" record at BYE time
instead of either writing a BYE record, or allowing me to update it
with a few custom fields, one of which would be t_end or something.

Cheers,
Kingsley.

On Thu, 2021-04-08 at 09:17 -0500, Marcin Groszek wrote:
> Because you are using dialog that invite entry in acc table is
> written at the time of bye. 
> I prefer a single entry in acc table for each call, not 2
> 
> Best regards:
> Marcin Groszek
> 
> > On Apr 8, 2021, at 8:15 AM, Kingsley Tart 
> > wrote:
> > 
> > Thanks, though that didn't seem to have made any difference :(
> > 
> > It *is* logging durations though (something you mentioned in your
> > other
> > email).
> > 
> > Cheers,
> > Kingsley.


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

Re: [OpenSIPS-Users] OpenSIPS 3.1 DB logging INVITEs but not BYEs

[Kingsley Tart]

Thanks, though that didn't seem to have made any difference :(

It *is* logging durations though (something you mentioned in your other
email).

Cheers,
Kingsley.

On Thu, 2021-04-08 at 07:10 -0500, Marcin Groszek wrote:
> remove
> 
> t_newtran();
> 
> 
> On 4/8/2021 5:55 AM, Kingsley Tart wrote:
> > Hi,
> > 
> > I'm using OpenSIPS 3.1 with logging to DB and using the dialog
> > module.
> > 
> > It is logging INVITE messages, but not BYE and I can't see why. I'm
> > new
> > to OpenSIPS so this is puzzling me a bit.
> > 
> > 
> > This is what I'm setting in the acc module:
> > 
> > loadmodule "acc.so"
> > modparam("acc", "early_media", 1)
> > modparam("acc", "report_cancels", 1)
> > modparam("acc", "detect_direction", 0)
> > modparam("acc", "db_url", "mysql://blah...")
> > 
> > 
> > My main route script starts with this:
> > 
> > script_trace(1, "method $rm");
> > 
> > 
> > I'm doing this when an INVITE comes in:
> > 
> > t_newtran();
> > create_dialog("pPB");
> > do_accounting("db", "cdr|missed|failed");
> > 
> > 
> > I have this, but it made no difference (although "BYE RECEIVED" did
> > appear in the opensips log):
> > 
> > if (is_method("BYE")) {
> > # do accounting even if the transaction fails
> > xlog("BYE RECEIVED");
> > do_accounting("db", "cdr|missed|failed");
> > }
> > 
> > 
> > I have this event route:
> > 
> > event_route[E_DLG_STATE_CHANGED] {
> > switch ($param(7)) {
> > case 1:
> > xlog("** DLG ** INVITE SENT");
> > break;
> > case 2:
> > xlog("** DLG ** PROVISIONAL REPLY");
> > break;
> > case 3:
> > xlog("** DLG ** PROVISIONALLY ANSWERED");
> > break;
> > case 4:
> > xlog("** DLG ** CONFIRMED ANSWERED");
> > break;
> > case 5:
> > xlog("** DLG ** BYE RECEIVED - ENDED");
> > break;
> > }
> > }
> > 
> > 
> > and I see this in the opensips log when the call ends (I see
> > "do_accounting" in the trace):
> > 
> > /usr/sbin/opensips[22551]: ** DLG ** BYE RECEIVED - ENDED
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:225][core if] -> (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:220][module validate_dialog] ->
> > (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:230][core if] -> (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:225][module is_method] -> (method
> > BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:238][core if] -> (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:230][module is_method] -> (method
> > BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:233][module do_accounting] ->
> > (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:238][route relay] -> (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:431][core if] -> (method BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:428][module t_relay] -> (method
> > BYE)
> > /usr/sbin/opensips[22552]: [Script
> > Trace][/etc/opensips/opensips.cfg:431][core exit] -> (method BYE)
> > 
> > 
> > But the acc table only ever gets INVITEs logged; here are records
> > for
> > the last 2 test calls:
> > 
> > MariaDB [opensips]> SELECT id,method,callid,sip_code FROm acc ORDER
> > BY
> > id DESC LIMIT 4;
> > +-++--+--+
> > > id  | method | callid   | sip_code |
> > 
> > +-++--+--+
> > > 234 | INVITE | 18d9cfb9-5add-4824-9d19-b828c10df9f4 | 200  |
> > > 233 | INVITE | 18d9cfb9-5add-4824-9d19-b828c10df9f4 | 183  |
> > > 232 | INVITE | a3a3f3b3-3ac0-45de-8cb7-f208b2d420d0 | 200  |
> > > 231 | INVITE | a3a3f3b3-3ac0-45de-8cb7-f208b2d420d0 | 183  |
> > 
> > +-++--+--+
> > 
> > 
> > Am I missing something obvious?
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > 




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

[OpenSIPS-Users] OpenSIPS 3.1 DB logging INVITEs but not BYEs

[Kingsley Tart]

Hi,

I'm using OpenSIPS 3.1 with logging to DB and using the dialog module.

It is logging INVITE messages, but not BYE and I can't see why. I'm new
to OpenSIPS so this is puzzling me a bit.


This is what I'm setting in the acc module:

loadmodule "acc.so"
modparam("acc", "early_media", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
modparam("acc", "db_url", "mysql://blah...")


My main route script starts with this:

script_trace(1, "method $rm");


I'm doing this when an INVITE comes in:

t_newtran();
create_dialog("pPB");
do_accounting("db", "cdr|missed|failed");


I have this, but it made no difference (although "BYE RECEIVED" did
appear in the opensips log):

if (is_method("BYE")) {
# do accounting even if the transaction fails
xlog("BYE RECEIVED");
do_accounting("db", "cdr|missed|failed");
}


I have this event route:

event_route[E_DLG_STATE_CHANGED] {
switch ($param(7)) {
case 1:
xlog("** DLG ** INVITE SENT");
break;
case 2:
xlog("** DLG ** PROVISIONAL REPLY");
break;
case 3:
xlog("** DLG ** PROVISIONALLY ANSWERED");
break;
case 4:
xlog("** DLG ** CONFIRMED ANSWERED");
break;
case 5:
xlog("** DLG ** BYE RECEIVED - ENDED");
break;
}
}


and I see this in the opensips log when the call ends (I see
"do_accounting" in the trace):

/usr/sbin/opensips[22551]: ** DLG ** BYE RECEIVED - ENDED
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:225][core 
if] -> (method BYE)
/usr/sbin/opensips[22552]: [Script 
Trace][/etc/opensips/opensips.cfg:220][module validate_dialog] -> (method BYE)
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:230][core 
if] -> (method BYE)
/usr/sbin/opensips[22552]: [Script 
Trace][/etc/opensips/opensips.cfg:225][module is_method] -> (method BYE)
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:238][core 
if] -> (method BYE)
/usr/sbin/opensips[22552]: [Script 
Trace][/etc/opensips/opensips.cfg:230][module is_method] -> (method BYE)
/usr/sbin/opensips[22552]: [Script 
Trace][/etc/opensips/opensips.cfg:233][module do_accounting] -> (method BYE)
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:238][route 
relay] -> (method BYE)
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:431][core 
if] -> (method BYE)
/usr/sbin/opensips[22552]: [Script 
Trace][/etc/opensips/opensips.cfg:428][module t_relay] -> (method BYE)
/usr/sbin/opensips[22552]: [Script Trace][/etc/opensips/opensips.cfg:431][core 
exit] -> (method BYE)


But the acc table only ever gets INVITEs logged; here are records for
the last 2 test calls:

MariaDB [opensips]> SELECT id,method,callid,sip_code FROm acc ORDER BY
id DESC LIMIT 4;
+-++--+--+
| id  | method | callid   | sip_code |
+-++--+--+
| 234 | INVITE | 18d9cfb9-5add-4824-9d19-b828c10df9f4 | 200  |
| 233 | INVITE | 18d9cfb9-5add-4824-9d19-b828c10df9f4 | 183  |
| 232 | INVITE | a3a3f3b3-3ac0-45de-8cb7-f208b2d420d0 | 200  |
| 231 | INVITE | a3a3f3b3-3ac0-45de-8cb7-f208b2d420d0 | 183  |
+-++--+--+


Am I missing something obvious?

Cheers,
Kingsley.


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

[OpenSIPS-Users] variable interpolation in strings

[Kingsley Tart]

Hi,

I'm using OpenSIPS 3.1.

Why does this code:

$var(oldstr) = "sip:_44*121-1234@";
$var(uriOLD) = "<$var(oldstr)batty.com;user=phone>";
xlog("TEST=<$var(oldstr)batty.com;user=phone>");
xlog("uriOLD=$var(uriOLD)");

Result in these log entries?

TEST=
uriOLD=<$var(oldstr)batty.com;user=phone>

ie, why do the two values differ?

Cheers,
Kingsley.


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

Re: [OpenSIPS-Users] dp_translate() on other headers?

[Kingsley Tart]

Hi,

Thanks - yes I had realised that but it was the string manipulation of
the header itself that I was mainly thinking about.

I'm thinking that using a regex match on what is between "sip:" and "@"
would hopefully be OK with no false matches anywhere else in the
string, but there is no guarantee this would always be the case if
someone has a strange name string for example.

I like the string transformations - they're a really neat and safe way
of extracting the user part of the SIP address in this scenario; I was
trying to figure out whether there was an equally neat way of putting a
changed user value back into a URI string and nameaddr string without
having to re-construct the URI from its individual parts. 

I tried using construct_uri as below, but when one of the parameters
was null, the string "" got inserted, instead of being ignored:

$var(testURI) = $(var(testRPID){nameaddr.uri});
xlog("oldURI=$var(testURI)");

# wrapped in email but not in the routing script:
construct_uri("$(var(testURI){uri.schema})", "01234567890",
  "$(var(testURI){uri.host})", "$(var(testURI){uri.port})",
  "$(var(testURI){uri.params})", $avp(newURI));

xlog("newURI=$avp(newURI)");

Then this was logged:

oldURI=sip:07890123456@83.121.44.30:5060
newURI=sip:01234567890@83.121.44.30:5060;

If I don't put quotes around $(var(testURI){uri.params}) then it
complains that this isn't a string.

I know I could create the individual parts with a series of if (thing
== NULL) statements, but that seems quite longwinded and I was
wondering whether there was a better way.

Cheers,
Kingsley.

On Mon, 2021-03-29 at 10:22 +0300, Răzvan Crainea wrote:
> Hi, Kingsley!
> 
> The only way to do this is to remove the header and add a new one
> using 
> remove_hf/append_hf functions.
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 3/26/21 6:09 PM, Kingsley Tart wrote:
> > Hi,
> > 
> > I'm using OpenSIPS 3.1.
> > 
> > I've set up some dialplan rule sets to normalise numbers depending
> > on
> > the carrier, eg:
> > 
> > +---+-+--+
> > > match_exp | subst_exp   | repl_exp |
> > 
> > +---+-+--+
> > > ^\+44[1-9][0-9]+$ | ^\+44([1-9][0-9]+)$ | 0\1  |
> > > ^\+[1-9][0-9]+$   | ^\+([1-9][0-9]+)$   | 00\1 |
> > > ^\+44\*[0-9]+$| ^\+44\*([0-9]+)$| \1   |
> > 
> > +---+-+--+
> > 
> > but I also need to do this with other headers that may be present
> > and
> > contain numbers, eg
> > 
> > P-Asserted-Identity
> > P-Preferred-Identity
> > Remote-Party-ID
> > 
> > I know I can extract the number from the header eg like this:
> > 
> > if (is_present_hf(P-Asserted-Identity)) {
> >if (dp_translate(1, $(hdr(P-Asserted-
> > Identity){nameaddr.uri}{uri.user}), $var(newnum))) {
> >  xlog("New value is $var(newnum)");
> >}
> > }
> > 
> > but is there an equally neat way of putting the new value back
> > inside
> > the header string? I can't use $(hdr(P-Asserted-
> > Identity){nameaddr.uri}{uri.user}) as an lvalue.
> > 
> > Otherwise I presume I'm going to have to make my dialplan regex
> > matches
> > try to home in on the number part by having "sip:" instead of my
> > "^"
> > anchor and "@" instead of my "$" anchor in the match rule and hope
> > that
> > doesn't happen to match anything else in the header (unlikely I
> > know,
> > but not impossible).
> > 
> > Forgive me if I've missed something obvious - I'm new to OpenSIPS.
> > 
> > Cheers,
> > Kingsley.
> > 
> > 
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users




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

[OpenSIPS-Users] dp_translate() on other headers?

[Kingsley Tart]

Hi,

I'm using OpenSIPS 3.1.

I've set up some dialplan rule sets to normalise numbers depending on
the carrier, eg:

+---+-+--+
> match_exp | subst_exp   | repl_exp |

+---+-+--+
> ^\+44[1-9][0-9]+$ | ^\+44([1-9][0-9]+)$ | 0\1  |
> ^\+[1-9][0-9]+$   | ^\+([1-9][0-9]+)$   | 00\1 |
> ^\+44\*[0-9]+$| ^\+44\*([0-9]+)$| \1   |

+---+-+--+

but I also need to do this with other headers that may be present and
contain numbers, eg

P-Asserted-Identity
P-Preferred-Identity
Remote-Party-ID

I know I can extract the number from the header eg like this:

if (is_present_hf(P-Asserted-Identity)) {
  if (dp_translate(1, $(hdr(P-Asserted-
Identity){nameaddr.uri}{uri.user}), $var(newnum))) {
xlog("New value is $var(newnum)");
  }
}

but is there an equally neat way of putting the new value back inside
the header string? I can't use $(hdr(P-Asserted-
Identity){nameaddr.uri}{uri.user}) as an lvalue.

Otherwise I presume I'm going to have to make my dialplan regex matches
try to home in on the number part by having "sip:" instead of my "^"
anchor and "@" instead of my "$" anchor in the match rule and hope that
doesn't happen to match anything else in the header (unlikely I know,
but not impossible).

Forgive me if I've missed something obvious - I'm new to OpenSIPS.

Cheers,
Kingsley.


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