[SR-Users] Re: Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)

[George Diamantopoulos via sr-users]

Hello Karsten,

Thank you for your reply. I have opened an issue at
https://github.com/kamailio/kamailio/issues/3757

BR,
George

On Thu, 15 Feb 2024 at 18:39, Karsten Horsmann  wrote:

> Hi George,
>
>
> if you think it's a issue please fill a bug report on Github to let the
> Devs investigate. Also the questions in the form ask for all what they
> need.
>
> Thank you
>
> George Diamantopoulos via sr-users  schrieb
> am Do., 15. Feb. 2024, 16:06:
>
>> Update: I have just downgraded to 5.6.4 using
>> https://deb-archive.kamailio.org/repos/kamailio-5.6.4
>>
>> I have confirmed that topos works correctly with this version, so the
>> commit that broke things happened between 5.6.4 and 5.6.5
>>
>> It might be related to how multi-homed installations interact with topos
>> when doing double rr. Tne difference I noticed is that in 5.6.4, the topos
>> substitution in Via is:
>> * inbound: Via: SIP/2.0/UDP 195.167.21.66:5060
>> ;branch=z9hG4bKq27z808ysq87yrzq6vp8m26yq;Role=3;Hpt=8e88_16
>> * outbound: Via: SIP/2.0/UDP
>> 172.30.154.1;branch=z9hG4bKae0b.fce5449c22b5e79eb01d4f1ab3f7c014.0
>>
>> That is kamailio replaces the hop with its internal interface. With topos
>> on in 5.6.5, the behaviour is different for the UPDATE:
>> * inbound: Via: SIP/2.0/UDP 195.167.21.66:5060
>> ;branch=z9hG4bK1jo121j8j2h5h3wzh2mzj51q5;Role=3;Hpt=8ea8_16
>> * outbound: Via: SIP/2.0/UDP
>> 185.73.42.241;branch=z9hG4bKc45b.e6226bcf14264ae3b8674dd25a71191c.0
>>
>> 185.73.42.241 is an interface on the same instance, but represents its
>> "public" interface. Additionally, it happens to reside on a VRF, so the
>> 200OK never reaches it because the routing table of the UAS directs it to
>> another host with the same IP.
>>
>> Hopefully this is enough to get an idea of what might have gone wrong?
>> Thanks!
>>
>> On Thu, 15 Feb 2024 at 15:55, George Diamantopoulos 
>> wrote:
>>
>>> Hello all,
>>>
>>> I've noticed that there seems to be a regression with the topos module,
>>> more specifically the redis flavour, but I'm assuming the storage backend
>>> shouldn't make a difference.
>>> I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm
>>> assuming some backported commit is to blame. Kamailio 5.6.4 used
>>> previously, to the best of my memory, was not affected.
>>>
>>> Early dialog UPDATEs sent from the callee seem to be somehow malformed,
>>> since the 200 OK the UAS produces goes directly to the UAC despite having
>>> executed record_route() for the original INVITE. I can't imagine how this
>>> is possible, I thought responses always honour the Via header and record
>>> route shouldn't play a role in this case, right?
>>>
>>> Simply turning topos off restores the intended behaviour, however, so I
>>> can't help but think this is somehow related. Here's two call flows
>>> demonstrating the behaviour:
>>> * Topos on, 200 OK to UPDATE missing: https://pastebin.com/raw/J0zQeM5g
>>> * Topos off, 200 OK to UPDATE routed correctly:
>>> https://pastebin.com/raw/49yErezb
>>>
>>> I was wondering if anyone is aware of any commits that might be
>>> responsible for this. Additionally, is there an archive of debian packages
>>> with previous point releases so that I can confirm this regression with the
>>> latest versions?
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> George
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)

[George Diamantopoulos via sr-users]

Update: I have just downgraded to 5.6.4 using
https://deb-archive.kamailio.org/repos/kamailio-5.6.4

I have confirmed that topos works correctly with this version, so the
commit that broke things happened between 5.6.4 and 5.6.5

It might be related to how multi-homed installations interact with topos
when doing double rr. Tne difference I noticed is that in 5.6.4, the topos
substitution in Via is:
* inbound: Via: SIP/2.0/UDP 195.167.21.66:5060
;branch=z9hG4bKq27z808ysq87yrzq6vp8m26yq;Role=3;Hpt=8e88_16
* outbound: Via: SIP/2.0/UDP
172.30.154.1;branch=z9hG4bKae0b.fce5449c22b5e79eb01d4f1ab3f7c014.0

That is kamailio replaces the hop with its internal interface. With topos
on in 5.6.5, the behaviour is different for the UPDATE:
* inbound: Via: SIP/2.0/UDP 195.167.21.66:5060
;branch=z9hG4bK1jo121j8j2h5h3wzh2mzj51q5;Role=3;Hpt=8ea8_16
* outbound: Via: SIP/2.0/UDP
185.73.42.241;branch=z9hG4bKc45b.e6226bcf14264ae3b8674dd25a71191c.0

185.73.42.241 is an interface on the same instance, but represents its
"public" interface. Additionally, it happens to reside on a VRF, so the
200OK never reaches it because the routing table of the UAS directs it to
another host with the same IP.

Hopefully this is enough to get an idea of what might have gone wrong?
Thanks!

On Thu, 15 Feb 2024 at 15:55, George Diamantopoulos 
wrote:

> Hello all,
>
> I've noticed that there seems to be a regression with the topos module,
> more specifically the redis flavour, but I'm assuming the storage backend
> shouldn't make a difference.
> I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm assuming
> some backported commit is to blame. Kamailio 5.6.4 used previously, to the
> best of my memory, was not affected.
>
> Early dialog UPDATEs sent from the callee seem to be somehow malformed,
> since the 200 OK the UAS produces goes directly to the UAC despite having
> executed record_route() for the original INVITE. I can't imagine how this
> is possible, I thought responses always honour the Via header and record
> route shouldn't play a role in this case, right?
>
> Simply turning topos off restores the intended behaviour, however, so I
> can't help but think this is somehow related. Here's two call flows
> demonstrating the behaviour:
> * Topos on, 200 OK to UPDATE missing: https://pastebin.com/raw/J0zQeM5g
> * Topos off, 200 OK to UPDATE routed correctly:
> https://pastebin.com/raw/49yErezb
>
> I was wondering if anyone is aware of any commits that might be
> responsible for this. Additionally, is there an archive of debian packages
> with previous point releases so that I can confirm this regression with the
> latest versions?
>
> Thank you!
>
> Best regards,
> George
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)

[George Diamantopoulos via sr-users]

Hello all,

I've noticed that there seems to be a regression with the topos module,
more specifically the redis flavour, but I'm assuming the storage backend
shouldn't make a difference.
I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm assuming
some backported commit is to blame. Kamailio 5.6.4 used previously, to the
best of my memory, was not affected.

Early dialog UPDATEs sent from the callee seem to be somehow malformed,
since the 200 OK the UAS produces goes directly to the UAC despite having
executed record_route() for the original INVITE. I can't imagine how this
is possible, I thought responses always honour the Via header and record
route shouldn't play a role in this case, right?

Simply turning topos off restores the intended behaviour, however, so I
can't help but think this is somehow related. Here's two call flows
demonstrating the behaviour:
* Topos on, 200 OK to UPDATE missing: https://pastebin.com/raw/J0zQeM5g
* Topos off, 200 OK to UPDATE routed correctly:
https://pastebin.com/raw/49yErezb

I was wondering if anyone is aware of any commits that might be responsible
for this. Additionally, is there an archive of debian packages with
previous point releases so that I can confirm this regression with the
latest versions?

Thank you!

Best regards,
George
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Logs suddenly inundated with qm_malloc errors

[George Diamantopoulos]

Hello all,

I'm testing out release 5.6.2 on one production kamailio instance, and
today our monitoring system triggered an alarm for lack of disk space on /.
Indeed, kamailio.log started growing at an alarming rate at some point.

At about the same time disk space started being depleted, the following
line was frequently logged in the logs (no instances of it before that
time):

qm_malloc(): qm_malloc(0x7f5ade9c0010, 536) called from rtpengine:
bencode.c: __bencode_piece_new(79), module: rtpengine; Free fragment not
found!

They don't only concern rtpengine, core has produced similar "free fragment
not found" errors as well. There's additional multiple "had header field",
"bad header" and "invalid header name" errors appearing after that too, but
I'm guessing that's only a symptom of the qm_malloc issue?

kamailio is started with -m 2048 -M 16 and there's another instance with
almost identical traffic and configuration, but running on 5.6.1, which has
never exhibited such failures in several months uptime. So I'm wondering,
is there anything in 5.6.2 that could explain this? Thanks!

Best regards,
George
__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Releasing v5.6.1

[George Diamantopoulos]

Hello all,

Thank you to all who contributed to this release. I'm not seeing packages
for debian yet. Perhaps there's some issue with the build bots? I don't
remember it having taken that long for binaries to appear with previous
releases. Thanks!

BR,
George

On Fri, 8 Jul 2022 at 12:18, Patrick Karton 
wrote:

> Thanks. All the team.
>
> Just one question on which base commit pull  requests are merged in
> current branch.
>
> i see some new master commits not been merged in this release.
>
> especially
>
> ims_qos: fix module loading crash
>
> 0550a3d44b2addc160b6a20bd2c9bf2831187400
>
> tm: new param to specify reply codes for dns srv failover
> 062e6daa0f149e01674667f77608afb35b6e099a
>
> Thanks.
> --
> *De :* sr-users  de la part de
> Daniel-Constantin Mierla 
> *Envoyé :* mercredi 6 juillet 2022 07:38
> *À :* Kamailio (SER) - Users Mailing List ;
> Kamailio (SER) - Devel Mailing List 
> *Objet :* Re: [SR-Users] Releasing v5.6.1
>
> Hello,
>
> short notification that the Kamailio 5.6.1 will be released today,
> therefore any commits to branch 5.6 should be announced to the sr-dev
> mailing list and wait for the ack before pushing to github repo. Once
> the announcement of the release is out, commits can be pushed as usual.
>
> Cheers,
> Daniel
>
> On 24.06.22 10:35, Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > I am considering to release Kamailio v5.6.1 (out of branch 5.6) on
> > Wednesday, July 6, 2022 -- in about 1 week and a half from now. If
> > anyone is aware of issues not yet on the bug tracker, report them there
> > asap in order to have a better chance to be fixed.
> >
> > Cheers,
> > Daniel
> >
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello Henning,

Thanks for the reply. Here's the output, but I don't see anything relevant
to git commits:

version: kamailio 5.6.0-rc0 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1

BR,
George

On Tue, 10 May 2022 at 18:55, Henning Westerholt  wrote:

> Hello,
>
>
>
> it seems to be included, at least in the git branch.
>
>
>
> ~/repositories/5.6$ git log | egrep "c309122|ceb688b" -A 5
>
> commit c309122864eaa2bfa58253290bed49084ccc9302
>
> Author: Daniel-Constantin Mierla mico...@gmail.com
>
> Date:   Thu Apr 21 14:28:26 2022 +0200
>
>
>
> topos: restore attributes based on direction for early dialog requests
>
>
>
> --
>
> commit ceb688b3d364bb7b8d9f52b7238d560cb4e30b3d
>
> Author: Daniel-Constantin Mierla mico...@gmail.com
>
> Date:   Thu Apr 21 09:00:09 2022 +0200
>
>
>
> topos: use direction for loading invite record for other early dialog
> requests
>
>
>
> It would be good to double-check with the output of “kamailio -v”, please
> paste it here.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* George Diamantopoulos 
> *Sent:* Tuesday, May 10, 2022 4:43 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>
>
>
> Hello again,
>
>
>
> I've just tested 5.6.0~rc0+bpo11.20220506004754.1 from 56-nightly, but
> loose_route() still returns false for early-dialog UPDATE... Does this
> build include c309122 and ceb688b referenced in
> https://github.com/kamailio/kamailio/issues/3090?
>
>
>
> Cheers,
>
> George
>
>
>
> On Thu, 7 Apr 2022 at 10:21, George Diamantopoulos 
> wrote:
>
> Hello all,
>
>
>
> Thanks for the feedback, Henning. There seems to have already been a
> ticket about this but it's closed now:
> https://github.com/kamailio/kamailio/issues/2659
>
>
>
> I'm a little confused here. It seems early-dialog UPDATE should be handled
> similarly to PRACK, so I guess maybe a patch like
> https://github.com/kamailio/kamailio/commit/37830f53b1f21fba5beef5d8e22913c431dcd708
> would be needed.
>
>
>
> However, Daniel has commented in this issue about the need to do
> record_route() in config. To quote him: "The module requires record
> routing, so if the UPDATE requires to re-enforce Record-Route, then you
> have to do it. [...] I was aware that only NOTIFY requires to re-enforce
> Record-Route, but can be also a matter of UA implementation to want it for
> other requests."
>
>
>
> However, RR reinforcement for NOTIFY only happens (in the kamailio sample
> configuration file) in route[WITHINDLG] only if loose_route() check is
> successful. In my case, UPDATEs fail this test, so control goes directly to
> "sl_send_reply("404","Not here");", same as the author of the
> aforementioned ticket. Unless Daniel meant one needs to reinforce RR for
> PRACKs in order for subsequent UPDATEs to work?
>
>
>
> Any thoughts?
>
>
>
> BR,
>
> George
>
>
>
> On Wed, 6 Apr 2022 at 22:48, Henning Westerholt  wrote:
>
> Hello,
>
>
>
> Thanks for the update. Opening a github issue about it is probably a good
> idea.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Wednesday, April 6, 2022 7:29 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>
>
>
> This seems to be a topos issue regardless of backend, I tried with mariadb
> as storage and UPDATE routing fails in the same way as it does with redis.
> I'll probably open an issue on Github about this (early dialog UPDATE
> broken by topos). PRACK seems to work fine in my case. Direction of UPDATE
> vs PRACK however is different, not sure if that's important in any way.
>
>
>
> BR,
>
> George
>
>
>
> On Wed, 6 Apr 2022 at 06:31, George Diamantopoulos 
> wrote:
>
> Hello again,
>
>
>
> I have confirmed the problem 

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello again,

I've just tested 5.6.0~rc0+bpo11.20220506004754.1 from 56-nightly, but
loose_route() still returns false for early-dialog UPDATE... Does this
build include c309122 and ceb688b referenced in
https://github.com/kamailio/kamailio/issues/3090?

Cheers,
George

On Thu, 7 Apr 2022 at 10:21, George Diamantopoulos 
wrote:

> Hello all,
>
> Thanks for the feedback, Henning. There seems to have already been a
> ticket about this but it's closed now:
> https://github.com/kamailio/kamailio/issues/2659
>
> I'm a little confused here. It seems early-dialog UPDATE should be handled
> similarly to PRACK, so I guess maybe a patch like
> https://github.com/kamailio/kamailio/commit/37830f53b1f21fba5beef5d8e22913c431dcd708
> would be needed.
>
> However, Daniel has commented in this issue about the need to do
> record_route() in config. To quote him: "The module requires record
> routing, so if the UPDATE requires to re-enforce Record-Route, then you
> have to do it. [...] I was aware that only NOTIFY requires to re-enforce
> Record-Route, but can be also a matter of UA implementation to want it for
> other requests."
>
> However, RR reinforcement for NOTIFY only happens (in the kamailio sample
> configuration file) in route[WITHINDLG] only if loose_route() check is
> successful. In my case, UPDATEs fail this test, so control goes directly to
> "sl_send_reply("404","Not here");", same as the author of the
> aforementioned ticket. Unless Daniel meant one needs to reinforce RR for
> PRACKs in order for subsequent UPDATEs to work?
>
> Any thoughts?
>
> BR,
> George
>
> On Wed, 6 Apr 2022 at 22:48, Henning Westerholt  wrote:
>
>> Hello,
>>
>>
>>
>> Thanks for the update. Opening a github issue about it is probably a good
>> idea.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>>
>> Kamailio services – https://gilawa.com
>>
>>
>>
>> *From:* sr-users  *On Behalf Of *George
>> Diamantopoulos
>> *Sent:* Wednesday, April 6, 2022 7:29 PM
>> *To:* Kamailio (SER) - Users Mailing List 
>> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>>
>>
>>
>> This seems to be a topos issue regardless of backend, I tried with
>> mariadb as storage and UPDATE routing fails in the same way as it does with
>> redis. I'll probably open an issue on Github about this (early dialog
>> UPDATE broken by topos). PRACK seems to work fine in my case. Direction of
>> UPDATE vs PRACK however is different, not sure if that's important in any
>> way.
>>
>>
>>
>> BR,
>>
>> George
>>
>>
>>
>> On Wed, 6 Apr 2022 at 06:31, George Diamantopoulos 
>> wrote:
>>
>> Hello again,
>>
>>
>>
>> I have confirmed the problem doesn't manifest without loading the topos
>> module. I'll see if I can also try a different topos backend this week to
>> confirm if this is a topos_redis issue or topos in general.
>>
>>
>>
>> BR,
>>
>> George
>>
>>
>>
>> On Tue, 22 Mar 2022 at 17:11, George Diamantopoulos 
>> wrote:
>>
>> Hello Henning,
>>
>>
>>
>> This is on kamailio 5.5.4.
>>
>>
>>
>> I'll try with a different backend and without topos and post the result
>> here as soon as I find the time, just curious if anyone has stumbled on
>> this with topos_redis before. Thanks!
>>
>>
>>
>> BR,
>>
>> George
>>
>>
>>
>> On Tue, 22 Mar 2022 at 15:51, Henning Westerholt  wrote:
>>
>> Hello,
>>
>>
>>
>> please give a recent 5.5.x Kamailio a try. There was a fix regarding
>> early-dialog UPDATE handling in topos committed one year ago.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>>
>> Kamailio services – https://gilawa.com
>>
>>
>>
>> *From:* sr-users  *On Behalf Of *George
>> Diamantopoulos
>> *Sent:* Monday, March 21, 2022 11:53 PM
>> *To:* d.tr...@pocos.nl; Kamailio (SER) - Users Mailing List <
>> sr-users@lists.kamailio.org>
>> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>>
>>
>>
>> Hello all,
>>
>>
>>
>> Any chance this could be affecting early-dialog UPDATE methods as well? I
>> haven't tried with a different backend (mysql

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello all,

Thanks for the feedback, Henning. There seems to have already been a ticket
about this but it's closed now:
https://github.com/kamailio/kamailio/issues/2659

I'm a little confused here. It seems early-dialog UPDATE should be handled
similarly to PRACK, so I guess maybe a patch like
https://github.com/kamailio/kamailio/commit/37830f53b1f21fba5beef5d8e22913c431dcd708
would be needed.

However, Daniel has commented in this issue about the need to do
record_route() in config. To quote him: "The module requires record
routing, so if the UPDATE requires to re-enforce Record-Route, then you
have to do it. [...] I was aware that only NOTIFY requires to re-enforce
Record-Route, but can be also a matter of UA implementation to want it for
other requests."

However, RR reinforcement for NOTIFY only happens (in the kamailio sample
configuration file) in route[WITHINDLG] only if loose_route() check is
successful. In my case, UPDATEs fail this test, so control goes directly to
"sl_send_reply("404","Not here");", same as the author of the
aforementioned ticket. Unless Daniel meant one needs to reinforce RR for
PRACKs in order for subsequent UPDATEs to work?

Any thoughts?

BR,
George

On Wed, 6 Apr 2022 at 22:48, Henning Westerholt  wrote:

> Hello,
>
>
>
> Thanks for the update. Opening a github issue about it is probably a good
> idea.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Wednesday, April 6, 2022 7:29 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>
>
>
> This seems to be a topos issue regardless of backend, I tried with mariadb
> as storage and UPDATE routing fails in the same way as it does with redis.
> I'll probably open an issue on Github about this (early dialog UPDATE
> broken by topos). PRACK seems to work fine in my case. Direction of UPDATE
> vs PRACK however is different, not sure if that's important in any way.
>
>
>
> BR,
>
> George
>
>
>
> On Wed, 6 Apr 2022 at 06:31, George Diamantopoulos 
> wrote:
>
> Hello again,
>
>
>
> I have confirmed the problem doesn't manifest without loading the topos
> module. I'll see if I can also try a different topos backend this week to
> confirm if this is a topos_redis issue or topos in general.
>
>
>
> BR,
>
> George
>
>
>
> On Tue, 22 Mar 2022 at 17:11, George Diamantopoulos 
> wrote:
>
> Hello Henning,
>
>
>
> This is on kamailio 5.5.4.
>
>
>
> I'll try with a different backend and without topos and post the result
> here as soon as I find the time, just curious if anyone has stumbled on
> this with topos_redis before. Thanks!
>
>
>
> BR,
>
> George
>
>
>
> On Tue, 22 Mar 2022 at 15:51, Henning Westerholt  wrote:
>
> Hello,
>
>
>
> please give a recent 5.5.x Kamailio a try. There was a fix regarding
> early-dialog UPDATE handling in topos committed one year ago.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Monday, March 21, 2022 11:53 PM
> *To:* d.tr...@pocos.nl; Kamailio (SER) - Users Mailing List <
> sr-users@lists.kamailio.org>
> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>
>
>
> Hello all,
>
>
>
> Any chance this could be affecting early-dialog UPDATE methods as well? I
> haven't tried with a different backend (mysql) yet, but loose_route returns
> false...
>
>
>
> BR,
>
> George
>
>
>
> On Fri, 25 May 2018 at 18:00, Daniel Tryba  wrote:
>
> On Wed, May 23, 2018 at 10:51:37PM +0200, Daniel-Constantin Mierla wrote:
> > I got a bit of time to look at this issue, can you try with the patch
> > from the next commit?
> >
> > ?? -
> >
> https://github.com/kamailio/kamailio/commit/2a3ca5942291d29de05b14338a36cecbec11f129
> >
>
> This off by 1 fix solved the PRACK issue with redis backend.
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

This seems to be a topos issue regardless of backend, I tried with mariadb
as storage and UPDATE routing fails in the same way as it does with redis.
I'll probably open an issue on Github about this (early dialog UPDATE
broken by topos). PRACK seems to work fine in my case. Direction of UPDATE
vs PRACK however is different, not sure if that's important in any way.

BR,
George

On Wed, 6 Apr 2022 at 06:31, George Diamantopoulos 
wrote:

> Hello again,
>
> I have confirmed the problem doesn't manifest without loading the topos
> module. I'll see if I can also try a different topos backend this week to
> confirm if this is a topos_redis issue or topos in general.
>
> BR,
> George
>
> On Tue, 22 Mar 2022 at 17:11, George Diamantopoulos 
> wrote:
>
>> Hello Henning,
>>
>> This is on kamailio 5.5.4.
>>
>> I'll try with a different backend and without topos and post the result
>> here as soon as I find the time, just curious if anyone has stumbled on
>> this with topos_redis before. Thanks!
>>
>> BR,
>> George
>>
>> On Tue, 22 Mar 2022 at 15:51, Henning Westerholt  wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> please give a recent 5.5.x Kamailio a try. There was a fix regarding
>>> early-dialog UPDATE handling in topos committed one year ago.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Henning
>>>
>>>
>>>
>>> --
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>>
>>> Kamailio services – https://gilawa.com
>>>
>>>
>>>
>>> *From:* sr-users  *On Behalf Of *George
>>> Diamantopoulos
>>> *Sent:* Monday, March 21, 2022 11:53 PM
>>> *To:* d.tr...@pocos.nl; Kamailio (SER) - Users Mailing List <
>>> sr-users@lists.kamailio.org>
>>> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>>>
>>>
>>>
>>> Hello all,
>>>
>>>
>>>
>>> Any chance this could be affecting early-dialog UPDATE methods as well?
>>> I haven't tried with a different backend (mysql) yet, but loose_route
>>> returns false...
>>>
>>>
>>>
>>> BR,
>>>
>>> George
>>>
>>>
>>>
>>> On Fri, 25 May 2018 at 18:00, Daniel Tryba  wrote:
>>>
>>> On Wed, May 23, 2018 at 10:51:37PM +0200, Daniel-Constantin Mierla wrote:
>>> > I got a bit of time to look at this issue, can you try with the patch
>>> > from the next commit?
>>> >
>>> > ?? -
>>> >
>>> https://github.com/kamailio/kamailio/commit/2a3ca5942291d29de05b14338a36cecbec11f129
>>> >
>>>
>>> This off by 1 fix solved the PRACK issue with redis backend.
>>>
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello again,

I have confirmed the problem doesn't manifest without loading the topos
module. I'll see if I can also try a different topos backend this week to
confirm if this is a topos_redis issue or topos in general.

BR,
George

On Tue, 22 Mar 2022 at 17:11, George Diamantopoulos 
wrote:

> Hello Henning,
>
> This is on kamailio 5.5.4.
>
> I'll try with a different backend and without topos and post the result
> here as soon as I find the time, just curious if anyone has stumbled on
> this with topos_redis before. Thanks!
>
> BR,
> George
>
> On Tue, 22 Mar 2022 at 15:51, Henning Westerholt  wrote:
>
>> Hello,
>>
>>
>>
>> please give a recent 5.5.x Kamailio a try. There was a fix regarding
>> early-dialog UPDATE handling in topos committed one year ago.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>>
>> Kamailio services – https://gilawa.com
>>
>>
>>
>> *From:* sr-users  *On Behalf Of *George
>> Diamantopoulos
>> *Sent:* Monday, March 21, 2022 11:53 PM
>> *To:* d.tr...@pocos.nl; Kamailio (SER) - Users Mailing List <
>> sr-users@lists.kamailio.org>
>> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>>
>>
>>
>> Hello all,
>>
>>
>>
>> Any chance this could be affecting early-dialog UPDATE methods as well? I
>> haven't tried with a different backend (mysql) yet, but loose_route returns
>> false...
>>
>>
>>
>> BR,
>>
>> George
>>
>>
>>
>> On Fri, 25 May 2018 at 18:00, Daniel Tryba  wrote:
>>
>> On Wed, May 23, 2018 at 10:51:37PM +0200, Daniel-Constantin Mierla wrote:
>> > I got a bit of time to look at this issue, can you try with the patch
>> > from the next commit?
>> >
>> > ?? -
>> >
>> https://github.com/kamailio/kamailio/commit/2a3ca5942291d29de05b14338a36cecbec11f129
>> >
>>
>> This off by 1 fix solved the PRACK issue with redis backend.
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello Henning,

This is on kamailio 5.5.4.

I'll try with a different backend and without topos and post the result
here as soon as I find the time, just curious if anyone has stumbled on
this with topos_redis before. Thanks!

BR,
George

On Tue, 22 Mar 2022 at 15:51, Henning Westerholt  wrote:

> Hello,
>
>
>
> please give a recent 5.5.x Kamailio a try. There was a fix regarding
> early-dialog UPDATE handling in topos committed one year ago.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Monday, March 21, 2022 11:53 PM
> *To:* d.tr...@pocos.nl; Kamailio (SER) - Users Mailing List <
> sr-users@lists.kamailio.org>
> *Subject:* Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
>
>
>
> Hello all,
>
>
>
> Any chance this could be affecting early-dialog UPDATE methods as well? I
> haven't tried with a different backend (mysql) yet, but loose_route returns
> false...
>
>
>
> BR,
>
> George
>
>
>
> On Fri, 25 May 2018 at 18:00, Daniel Tryba  wrote:
>
> On Wed, May 23, 2018 at 10:51:37PM +0200, Daniel-Constantin Mierla wrote:
> > I got a bit of time to look at this issue, can you try with the patch
> > from the next commit?
> >
> > ?? -
> >
> https://github.com/kamailio/kamailio/commit/2a3ca5942291d29de05b14338a36cecbec11f129
> >
>
> This off by 1 fix solved the PRACK issue with redis backend.
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

[George Diamantopoulos]

Hello all,

Any chance this could be affecting early-dialog UPDATE methods as well? I
haven't tried with a different backend (mysql) yet, but loose_route returns
false...

BR,
George

On Fri, 25 May 2018 at 18:00, Daniel Tryba  wrote:

> On Wed, May 23, 2018 at 10:51:37PM +0200, Daniel-Constantin Mierla wrote:
> > I got a bit of time to look at this issue, can you try with the patch
> > from the next commit?
> >
> > ?? -
> >
> https://github.com/kamailio/kamailio/commit/2a3ca5942291d29de05b14338a36cecbec11f129
> >
>
> This off by 1 fix solved the PRACK issue with redis backend.
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Experiences with Kamailio on Debian 11 Bullseye

[George Diamantopoulos]

I used packages from deb.kamailio.org, I didn't build kamailio myself.

BR,
George

On Wed, 19 Jan 2022 at 18:01, Daniel-Constantin Mierla 
wrote:

> You probably compiled kamcmd without libreadline-dev.
>
> However, I would recommend to use kamcli instead of kamcmd, the binrpc
> protocol and kamcmd are not really maintained.
>
> Cheers,
> Daniel
> On 19.01.22 12:11, George Diamantopoulos wrote:
>
> Hello,
>
> I'm happy to report there have been no serious regressions with the
> bullseye builds. Only thing I noticed is tab completion doesn't work with
> kamcmd.
>
> BR,
> George
>
> On Thu, 18 Nov 2021 at 18:36, Daniel-Constantin Mierla 
> wrote:
>
>> One thing that I noticed on a new Debian 11 system, deploying kamailio
>> from source code, was that some files/folders were created with
>> 0640/0750 by root, resulting on some commands not to work (e.g., as
>> kamailio user) .
>>
>> It could be specific to that system, how it was initially configured, I
>> though worth mentioning it here. I didn't spend time to analyze, changed
>> access mods manually. Otherwise all ok on that system, nothing complex
>> though, UDP intranet routing.
>>
>> Cheers,
>> Daniel
>>
>> On 18.11.21 04:24, Alex Balashov wrote:
>> > Using it on 11 in many places, works fine.
>> >
>> >> On Nov 17, 2021, at 10:22 PM, Joel Serrano  wrote:
>> >>
>> >> +1 here using Kam 5.5 and debian 11 in prod, we finished the migration
>> like a month ago and so far everything is going well.
>> >>
>> >> On Wed, Nov 17, 2021 at 12:57 PM Fred Posner  wrote:
>> >> Tested a 5.5.x build (with TLS) on Debian 11 (and raspbian) without
>> >> issue, but have been in test environments.
>> >>
>> >> Fred Posner | palner.com
>> >> Matrix: @fred:matrix.lod.com
>> >> o: +1 (212) 937-7844
>> >>
>> >> On 11/17/21 3:51 PM, Patrick Karton wrote:
>> >>> Hello,
>> >>>
>> >>> I am using kamailio 5.5.2 on debian 11 bullseye on kubernetes.
>> >>>
>> >>> Not Seen any issue so far.
>> >>>
>> >>> Le 17 nov. 2021 21:42, George Diamantopoulos  a
>> >>> écrit :
>> >>>
>> >>> Hello all,
>> >>>
>> >>> I'm also considering an upgrade in the coming weeks, but I'm a
>> >>> little reluctant seeing there has been no feedback from anyone on
>> >>> the list.
>> >>> I'll try it with an instance I can quickly restore back first and
>> >>> let the list know if there's any unexpected issues (or not).
>> >>>
>> >>> If anyone's tried the bullseye builds and hasn't had any problems,
>> >>> I'd like to hear from them too :-).
>> >>>
>> >>> BR,
>> >>> George
>> >>>
>> >>> On Tue, 26 Oct 2021 at 09:35, Daniel-Constantin Mierla
>> >>> mailto:mico...@gmail.com>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> has anyone experienced issues with Kamailio running on Debian
>> 11
>> >>> Bullseye?
>> >>>
>> >>> It's now more than 2 months since Debian 11 release and I
>> wonder if
>> >>> people started to migrate to it for production systems.
>> >>>
>> >>> So far I did only basic tests on it, although I have a Debian
>> >>> Testing
>> >>> that I used for compilation and simple tests during the past
>> several
>> >>> months before Debian 11 release.
>> >>>
>> >>> If someone discovers issues or changes in behaviour with
>> various
>> >>> libraries or applications/database servers, report them to the
>> >>> tracker
>> >>> to try to address them as soon as possible.
>> >>>
>> >>> Cheers,
>> >>> Daniel
>> >>>
>> >>> --
>> >>> Daniel-Constantin Mierla -- www.asipto.com <
>> http://www.asipto.com>
>> >>> www.twitter.com/miconda <http://www.twitter.com/miconda> --
>> >>> www.linkedin.com/in/miconda <
>> http://www.linkedin.com/in/miconda>
>> >>> Kamailio Advanced Training

Re: [SR-Users] Experiences with Kamailio on Debian 11 Bullseye

[George Diamantopoulos]

Hello,

I'm happy to report there have been no serious regressions with the
bullseye builds. Only thing I noticed is tab completion doesn't work with
kamcmd.

BR,
George

On Thu, 18 Nov 2021 at 18:36, Daniel-Constantin Mierla 
wrote:

> One thing that I noticed on a new Debian 11 system, deploying kamailio
> from source code, was that some files/folders were created with
> 0640/0750 by root, resulting on some commands not to work (e.g., as
> kamailio user) .
>
> It could be specific to that system, how it was initially configured, I
> though worth mentioning it here. I didn't spend time to analyze, changed
> access mods manually. Otherwise all ok on that system, nothing complex
> though, UDP intranet routing.
>
> Cheers,
> Daniel
>
> On 18.11.21 04:24, Alex Balashov wrote:
> > Using it on 11 in many places, works fine.
> >
> >> On Nov 17, 2021, at 10:22 PM, Joel Serrano  wrote:
> >>
> >> +1 here using Kam 5.5 and debian 11 in prod, we finished the migration
> like a month ago and so far everything is going well.
> >>
> >> On Wed, Nov 17, 2021 at 12:57 PM Fred Posner  wrote:
> >> Tested a 5.5.x build (with TLS) on Debian 11 (and raspbian) without
> >> issue, but have been in test environments.
> >>
> >> Fred Posner | palner.com
> >> Matrix: @fred:matrix.lod.com
> >> o: +1 (212) 937-7844
> >>
> >> On 11/17/21 3:51 PM, Patrick Karton wrote:
> >>> Hello,
> >>>
> >>> I am using kamailio 5.5.2 on debian 11 bullseye on kubernetes.
> >>>
> >>> Not Seen any issue so far.
> >>>
> >>> Le 17 nov. 2021 21:42, George Diamantopoulos  a
> >>> écrit :
> >>>
> >>> Hello all,
> >>>
> >>> I'm also considering an upgrade in the coming weeks, but I'm a
> >>> little reluctant seeing there has been no feedback from anyone on
> >>> the list.
> >>> I'll try it with an instance I can quickly restore back first and
> >>> let the list know if there's any unexpected issues (or not).
> >>>
> >>> If anyone's tried the bullseye builds and hasn't had any problems,
> >>> I'd like to hear from them too :-).
> >>>
> >>> BR,
> >>> George
> >>>
> >>> On Tue, 26 Oct 2021 at 09:35, Daniel-Constantin Mierla
> >>> mailto:mico...@gmail.com>> wrote:
> >>>
> >>> Hello,
> >>>
> >>> has anyone experienced issues with Kamailio running on Debian
> 11
> >>> Bullseye?
> >>>
> >>> It's now more than 2 months since Debian 11 release and I
> wonder if
> >>> people started to migrate to it for production systems.
> >>>
> >>> So far I did only basic tests on it, although I have a Debian
> >>> Testing
> >>> that I used for compilation and simple tests during the past
> several
> >>> months before Debian 11 release.
> >>>
> >>> If someone discovers issues or changes in behaviour with
> various
> >>> libraries or applications/database servers, report them to the
> >>> tracker
> >>> to try to address them as soon as possible.
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>> --
> >>> Daniel-Constantin Mierla -- www.asipto.com <
> http://www.asipto.com>
> >>> www.twitter.com/miconda <http://www.twitter.com/miconda> --
> >>> www.linkedin.com/in/miconda <
> http://www.linkedin.com/in/miconda>
> >>> Kamailio Advanced Training - Online
> >>> Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America
> >>> Timezone)
> >>>   *
> https://www.asipto.com/sw/kamailio-advanced-training-online/
> >>> <https://www.asipto.com/sw/kamailio-advanced-training-online/>
> >>>
> >>>
> >>> __
> >>> Kamailio - Users Mailing List - Non Commercial Discussions
> >>>   * sr-users@lists.kamailio.org  sr-users@lists.kamailio.org>
> >>> Important: keep the mailing list in the recipients, do not
> reply
> >>> only to the sender!
>

Re: [SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Hello again,

Indeed it must have been the version mismatch. I have upgraded all
instances to 5.5.3 and shm now reports reasonable numbers. Thanks!

BR,
George

On Fri, 7 Jan 2022 at 14:10, Daniel-Constantin Mierla 
wrote:

> Hello,
> On 07.01.22 13:04, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> I see, thanks for the response. I guess I'll try upgrading all instances
> to 5.5.x for now, and hopefully that will fix it. If not, I'll revert to
> 5.4.x and post here again. If the issue does manifest with all instances on
> 5.5.x however, what information should I collect to investigate this
> further? I'm guessing shm stats is a start, but is it enough?
>
> it is hard to say, starting with the stats and shm summary is good!
>
>
> Lastly, is sip_msg_shm_clone growing consistent with DMQ incompatibility
> between 5.5.x <-> 5.4.x, or should such memory leaks manifest in some other
> way in shm stats?
>
> If the leak manifests only when dmq is used, then troubleshooting has to
> be done with the same Kamailio version on all nodes, otherwise can be waste
> of time. The cloning function is used for other features as well, not only
> for dmq, could be other reasons to leak from it.
>
> Cheers,
> Daniel
>
>
>
> Cheers,
> George
>
> On Fri, 7 Jan 2022 at 13:20, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> if you do dmq replication between kamailio systems running different
>> major versions, then it is likely to get memory leaks due to replication of
>> data and most probably cannot be fixed. This is because internal structures
>> of modules (also dmq commands) can change, practically what an instance
>> does is not ensured to happen on the other instance. Just for example, from
>> my mind, htable got some changes during past releases, dmq also has
>> significant enhancements by getting support for more transport protocols.
>>
>> If you get memory leaks when you run same Kamailio major version on all
>> Kamailio nodes, then that can be troubleshoot and fixed.
>>
>> Happy new year,
>> Daniel
>> On 07.01.22 11:33, George Diamantopoulos wrote:
>>
>> Hello all and happy new year,
>>
>> I have some new information to share regarding this issue. I believe the
>> previous metrics I sent to the list might not be indicative of the way the
>> problem manifests. Here's what I believe so far:
>>   - Issue is exacerbated (or manifests) during moderate-to-high cps, or
>> grows linearly with total traffic processed since last restart
>>   - shm stats show a lot of memory consumed by sip_msg_shm_clone
>>   - also reproduced this time on bullseye with kamailio 5.5.3
>>
>> Here's some more meaningful stats taken at more appropriate times (i.e.
>> after more traffic has been processed) than the previous ones. These two
>> kamailio instances have identical configuration and traffic patterns:
>> - https://pastebin.com/gHa803kB for kamailio 5.5.3 showing high
>> sip_msg_shm_clone on debian bullseye
>> - https://pastebin.com/JbcZbbSQ for kamailio 5.4.6 on debian buster
>>
>> There is still DMQ use for these instances despite the version mismatch.
>> Unfortunately I can't migrate all DMQ nodes to 5.5.x at this time, not
>> unless I can have assurances that it is DMQ that causes this issue with shm
>> memory exhaustion...
>>
>> After shmem was exhausted on 5.5.3, it stopped processing traffic. I
>> issued a kamctl trap at that time but I'm assuming the backtrace won't show
>> much except for the inability to allocate shm? If you think the backtrace
>> at that point would be useful in any way, let me know and I'll try to share
>> it privately. In case it isn't useful, what other debugging information can
>> be gathered to dissect this issue? Thanks!
>>
>> BR,
>> George
>>
>> On Wed, 30 Jun 2021 at 19:20, Daniel-Constantin Mierla 
>> wrote:
>>
>>> Hello,
>>>
>>> for the sake of completion: the autoexpire should clean the items if
>>> they are not used during the expiration interval. If you want to get them
>>> deleted after first expiration interval always, see the updateexpire
>>> attribute for htable modparam.
>>>
>>> Also, note that replication should be done only between Kamailio
>>> instances with same major version, because there can be internal
>>> differences between major versions that can lead to unexpected behaviour.
>>> In other words, if you replicate, doing between two kamailio with version
>>> 5.5.x or between two kamailio with version 5.4.x, but not between a
>>> kamailkio 5.5.x and

Re: [SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Hello Daniel,

I see, thanks for the response. I guess I'll try upgrading all instances to
5.5.x for now, and hopefully that will fix it. If not, I'll revert to 5.4.x
and post here again. If the issue does manifest with all instances on 5.5.x
however, what information should I collect to investigate this further? I'm
guessing shm stats is a start, but is it enough?

Lastly, is sip_msg_shm_clone growing consistent with DMQ incompatibility
between 5.5.x <-> 5.4.x, or should such memory leaks manifest in some other
way in shm stats?

Cheers,
George

On Fri, 7 Jan 2022 at 13:20, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> if you do dmq replication between kamailio systems running different major
> versions, then it is likely to get memory leaks due to replication of data
> and most probably cannot be fixed. This is because internal structures of
> modules (also dmq commands) can change, practically what an instance does
> is not ensured to happen on the other instance. Just for example, from my
> mind, htable got some changes during past releases, dmq also has
> significant enhancements by getting support for more transport protocols.
>
> If you get memory leaks when you run same Kamailio major version on all
> Kamailio nodes, then that can be troubleshoot and fixed.
>
> Happy new year,
> Daniel
> On 07.01.22 11:33, George Diamantopoulos wrote:
>
> Hello all and happy new year,
>
> I have some new information to share regarding this issue. I believe the
> previous metrics I sent to the list might not be indicative of the way the
> problem manifests. Here's what I believe so far:
>   - Issue is exacerbated (or manifests) during moderate-to-high cps, or
> grows linearly with total traffic processed since last restart
>   - shm stats show a lot of memory consumed by sip_msg_shm_clone
>   - also reproduced this time on bullseye with kamailio 5.5.3
>
> Here's some more meaningful stats taken at more appropriate times (i.e.
> after more traffic has been processed) than the previous ones. These two
> kamailio instances have identical configuration and traffic patterns:
> - https://pastebin.com/gHa803kB for kamailio 5.5.3 showing high
> sip_msg_shm_clone on debian bullseye
> - https://pastebin.com/JbcZbbSQ for kamailio 5.4.6 on debian buster
>
> There is still DMQ use for these instances despite the version mismatch.
> Unfortunately I can't migrate all DMQ nodes to 5.5.x at this time, not
> unless I can have assurances that it is DMQ that causes this issue with shm
> memory exhaustion...
>
> After shmem was exhausted on 5.5.3, it stopped processing traffic. I
> issued a kamctl trap at that time but I'm assuming the backtrace won't show
> much except for the inability to allocate shm? If you think the backtrace
> at that point would be useful in any way, let me know and I'll try to share
> it privately. In case it isn't useful, what other debugging information can
> be gathered to dissect this issue? Thanks!
>
> BR,
> George
>
> On Wed, 30 Jun 2021 at 19:20, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> for the sake of completion: the autoexpire should clean the items if they
>> are not used during the expiration interval. If you want to get them
>> deleted after first expiration interval always, see the updateexpire
>> attribute for htable modparam.
>>
>> Also, note that replication should be done only between Kamailio
>> instances with same major version, because there can be internal
>> differences between major versions that can lead to unexpected behaviour.
>> In other words, if you replicate, doing between two kamailio with version
>> 5.5.x or between two kamailio with version 5.4.x, but not between a
>> kamailkio 5.5.x and a kamailio 5.4.x.
>>
>> The total amount of used memory in the stats file for 5.5 does not seem
>> to be high as a rough estimation. The highest by module is in htable, but
>> it is around 20MB. Maybe you took the stats too early, quickly after a
>> restart?
>> Cheers,
>> Daniel
>>
>> On 30.06.21 17:20, George Diamantopoulos wrote:
>>
>> Hello Daniel,
>>
>> Thanks for the feedback. I think I might have been too quick to blame
>> htable for this behaviour. In fact, version 5.4 seems to consume more
>> memory than 5.5 (175129776 bytes vs 20581096), which makes sense since it
>> has been running for longer (I missed the extra digit previously).
>>
>> So I'm not sure htable is to blame. On the other hand, I don't see any
>> other modules using up too much of shmem either, so maybe memory stats
>> can't provide the answer here?
>>
>> To answer your question, though, I do use DMQ and both tables that use it
>> hav

Re: [SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Hello all and happy new year,

I have some new information to share regarding this issue. I believe the
previous metrics I sent to the list might not be indicative of the way the
problem manifests. Here's what I believe so far:
  - Issue is exacerbated (or manifests) during moderate-to-high cps, or
grows linearly with total traffic processed since last restart
  - shm stats show a lot of memory consumed by sip_msg_shm_clone
  - also reproduced this time on bullseye with kamailio 5.5.3

Here's some more meaningful stats taken at more appropriate times (i.e.
after more traffic has been processed) than the previous ones. These two
kamailio instances have identical configuration and traffic patterns:
- https://pastebin.com/gHa803kB for kamailio 5.5.3 showing high
sip_msg_shm_clone on debian bullseye
- https://pastebin.com/JbcZbbSQ for kamailio 5.4.6 on debian buster

There is still DMQ use for these instances despite the version mismatch.
Unfortunately I can't migrate all DMQ nodes to 5.5.x at this time, not
unless I can have assurances that it is DMQ that causes this issue with shm
memory exhaustion...

After shmem was exhausted on 5.5.3, it stopped processing traffic. I issued
a kamctl trap at that time but I'm assuming the backtrace won't show much
except for the inability to allocate shm? If you think the backtrace at
that point would be useful in any way, let me know and I'll try to share it
privately. In case it isn't useful, what other debugging information can be
gathered to dissect this issue? Thanks!

BR,
George

On Wed, 30 Jun 2021 at 19:20, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> for the sake of completion: the autoexpire should clean the items if they
> are not used during the expiration interval. If you want to get them
> deleted after first expiration interval always, see the updateexpire
> attribute for htable modparam.
>
> Also, note that replication should be done only between Kamailio instances
> with same major version, because there can be internal differences between
> major versions that can lead to unexpected behaviour. In other words, if
> you replicate, doing between two kamailio with version 5.5.x or between two
> kamailio with version 5.4.x, but not between a kamailkio 5.5.x and a
> kamailio 5.4.x.
>
> The total amount of used memory in the stats file for 5.5 does not seem to
> be high as a rough estimation. The highest by module is in htable, but it
> is around 20MB. Maybe you took the stats too early, quickly after a restart?
> Cheers,
> Daniel
>
> On 30.06.21 17:20, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> Thanks for the feedback. I think I might have been too quick to blame
> htable for this behaviour. In fact, version 5.4 seems to consume more
> memory than 5.5 (175129776 bytes vs 20581096), which makes sense since it
> has been running for longer (I missed the extra digit previously).
>
> So I'm not sure htable is to blame. On the other hand, I don't see any
> other modules using up too much of shmem either, so maybe memory stats
> can't provide the answer here?
>
> To answer your question, though, I do use DMQ and both tables that use it
> have autoexpire set to the same value on both 5.4 and 5.5:
>
> /etc/kamailio# grep dmq kamailio-module-params.cfg
> modparam("dmq", "server_address", "sip:172.30.43.1:5090")
> modparam("dmq", "notification_address", "sip:
> dmq.services.mydomain.com:5090")
> modparam("dmq", "multi_notify", 1)
> modparam("htable", "enable_dmq", 1)
> modparam("htable", "htable",
> 'cid2hi=>size=8;autoexpire=600;dmqreplicate=1')
> modparam("htable", "htable",
> 'xcid2count=>size=8;autoexpire=600;dmqreplicate=1')
>
> On Wed, 30 Jun 2021 at 17:43, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> do you replicate items in the htable via dmq? Does the htable have
>> autoexpire value set?
>>
>> Cheers,
>> Daniel
>> On 30.06.21 13:54, George Diamantopoulos wrote:
>>
>> Forwarding my reply to the list, using gmail's reply button set Henning
>> as the sole recipient :-\
>>
>> -- Forwarded message -
>> From: George Diamantopoulos 
>> Date: Sat, 26 Jun 2021 at 02:25
>> Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
>> To: Henning Westerholt 
>>
>>
>> Hello Henning,
>>
>> Thanks for your reply. Here's what has come up after a few hours:
>>
>> shm55: https://pastebin.com/h9JCePmc
>> shm54: https://pastebin.com/Nx5xEEnA
>>
>> It seems to me htable is the culprit? Are you seeing anything different?
>> 54 has been running for 77020 seconds, 55 for 28521 (s

Re: [SR-Users] Experiences with Kamailio on Debian 11 Bullseye

[George Diamantopoulos]

Hello all,

I'm also considering an upgrade in the coming weeks, but I'm a little
reluctant seeing there has been no feedback from anyone on the list.
I'll try it with an instance I can quickly restore back first and let the
list know if there's any unexpected issues (or not).

If anyone's tried the bullseye builds and hasn't had any problems, I'd like
to hear from them too :-).

BR,
George

On Tue, 26 Oct 2021 at 09:35, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> has anyone experienced issues with Kamailio running on Debian 11 Bullseye?
>
> It's now more than 2 months since Debian 11 release and I wonder if
> people started to migrate to it for production systems.
>
> So far I did only basic tests on it, although I have a Debian Testing
> that I used for compilation and simple tests during the past several
> months before Debian 11 release.
>
> If someone discovers issues or changes in behaviour with various
> libraries or applications/database servers, report them to the tracker
> to try to address them as soon as possible.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
> Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone)
>   * https://www.asipto.com/sw/kamailio-advanced-training-online/
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Hello Daniel,

Thanks for the feedback. I think I might have been too quick to blame
htable for this behaviour. In fact, version 5.4 seems to consume more
memory than 5.5 (175129776 bytes vs 20581096), which makes sense since it
has been running for longer (I missed the extra digit previously).

So I'm not sure htable is to blame. On the other hand, I don't see any
other modules using up too much of shmem either, so maybe memory stats
can't provide the answer here?

To answer your question, though, I do use DMQ and both tables that use it
have autoexpire set to the same value on both 5.4 and 5.5:

/etc/kamailio# grep dmq kamailio-module-params.cfg
modparam("dmq", "server_address", "sip:172.30.43.1:5090")
modparam("dmq", "notification_address", "sip:dmq.services.mydomain.com:5090")

modparam("dmq", "multi_notify", 1)
modparam("htable", "enable_dmq", 1)
modparam("htable", "htable",
'cid2hi=>size=8;autoexpire=600;dmqreplicate=1')
modparam("htable", "htable",
'xcid2count=>size=8;autoexpire=600;dmqreplicate=1')

On Wed, 30 Jun 2021 at 17:43, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> do you replicate items in the htable via dmq? Does the htable have
> autoexpire value set?
>
> Cheers,
> Daniel
> On 30.06.21 13:54, George Diamantopoulos wrote:
>
> Forwarding my reply to the list, using gmail's reply button set Henning as
> the sole recipient :-\
>
> -- Forwarded message -
> From: George Diamantopoulos 
> Date: Sat, 26 Jun 2021 at 02:25
> Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
> To: Henning Westerholt 
>
>
> Hello Henning,
>
> Thanks for your reply. Here's what has come up after a few hours:
>
> shm55: https://pastebin.com/h9JCePmc
> shm54: https://pastebin.com/Nx5xEEnA
>
> It seems to me htable is the culprit? Are you seeing anything different?
> 54 has been running for 77020 seconds, 55 for 28521 (significantly less).
>
> I'm going to turn it off until we figure something out...
>
> BR,
> George
>
> On Fri, 25 Jun 2021 at 18:17, Henning Westerholt  wrote:
>
>> Hello,
>>
>>
>>
>> Good observation. Please run the memory statistics CLI commands to get
>> more hints about the module that might cause it (as per below link). Then
>> please report more details. If you can point to a particular module, you
>> can also open an issue on our tracker.
>>
>>
>>
>> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> *From:* sr-users  *On Behalf Of *George
>> Diamantopoulos
>> *Sent:* Friday, June 25, 2021 4:53 PM
>> *To:* Kamailio (SER) - Users Mailing List 
>> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>>
>>
>>
>> Hello all,
>>
>>
>>
>> I'm still investigating the (most likely non-kamailio-related) memory
>> leak of my previous message to the list, there have been no developments so
>> far. I'll update if anything changes.
>>
>>
>>
>> This concerns a new finding which seems to affect kamailio 5.5.x. I have
>> two kamailio instances receiving the same traffic via round-robin. I
>> upgraded only one of them to 5.5.1 and left the other to 5.4.6 as I feared
>> of any issues arising. I was lucky to do so, because with identical
>> configuration, 5.5.x seems to run out of SHM very quickly. Here are links
>> to graphs produced by our monitoring system:
>>
>>
>>
>> Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
>>
>> New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png
>>
>>
>>
>> The configuration uses mtree, htable, vars and vns extensively. Has
>> anyone come across anything similar? Let me know if I can provide any
>> further information to help disect this. Thanks!
>>
>>
>>
>> BR,
>>
>> George
>>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Forwarding my reply to the list, using gmail's reply button set Henning as
the sole recipient :-\

-- Forwarded message -
From: George Diamantopoulos 
Date: Sat, 26 Jun 2021 at 02:25
Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
To: Henning Westerholt 


Hello Henning,

Thanks for your reply. Here's what has come up after a few hours:

shm55: https://pastebin.com/h9JCePmc
shm54: https://pastebin.com/Nx5xEEnA

It seems to me htable is the culprit? Are you seeing anything different? 54
has been running for 77020 seconds, 55 for 28521 (significantly less).

I'm going to turn it off until we figure something out...

BR,
George

On Fri, 25 Jun 2021 at 18:17, Henning Westerholt  wrote:

> Hello,
>
>
>
> Good observation. Please run the memory statistics CLI commands to get
> more hints about the module that might cause it (as per below link). Then
> please report more details. If you can point to a particular module, you
> can also open an issue on our tracker.
>
>
>
> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Friday, June 25, 2021 4:53 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>
>
>
> Hello all,
>
>
>
> I'm still investigating the (most likely non-kamailio-related) memory leak
> of my previous message to the list, there have been no developments so far.
> I'll update if anything changes.
>
>
>
> This concerns a new finding which seems to affect kamailio 5.5.x. I have
> two kamailio instances receiving the same traffic via round-robin. I
> upgraded only one of them to 5.5.1 and left the other to 5.4.6 as I feared
> of any issues arising. I was lucky to do so, because with identical
> configuration, 5.5.x seems to run out of SHM very quickly. Here are links
> to graphs produced by our monitoring system:
>
>
>
> Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
>
> New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png
>
>
>
> The configuration uses mtree, htable, vars and vns extensively. Has anyone
> come across anything similar? Let me know if I can provide any further
> information to help disect this. Thanks!
>
>
>
> BR,
>
> George
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Possible memory leak on 5.5.x (new)?

[George Diamantopoulos]

Hello all,

I'm still investigating the (most likely non-kamailio-related) memory leak
of my previous message to the list, there have been no developments so far.
I'll update if anything changes.

This concerns a new finding which seems to affect kamailio 5.5.x. I have
two kamailio instances receiving the same traffic via round-robin. I
upgraded only one of them to 5.5.1 and left the other to 5.4.6 as I feared
of any issues arising. I was lucky to do so, because with identical
configuration, 5.5.x seems to run out of SHM very quickly. Here are links
to graphs produced by our monitoring system:

Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png

The configuration uses mtree, htable, vars and vns extensively. Has anyone
come across anything similar? Let me know if I can provide any further
information to help disect this. Thanks!

BR,
George
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Possible memory leak?

[George Diamantopoulos]

Hello all,

I've been experiencing memory exhaustion (all 8GiB of it) on hosts running
kamailio for quite some time now while on the 5.4.x train. I can't really
say about previous versions, because the setup was quite different back
when I was using those.

After about 2 days of operation, RAM is exhausted and kamailio is killed by
the kernel OOM which frees up memory again. Restarting kamailio via systemd
will also free up most memory. I can't seem to find what is using it up, so
I'm guessing there might be a memory leak, but I'm not 100% sure so I
thought I'd ask the list for opinions.

I'm including the output of kamcmd pkg and shm stats and kamctl stats here.
My take on those is that there's nothing to show where all this RAM is
going. Kamailio version is 5.4.5+bpo10 on debian buster and is started with
'-P /run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.cfg -m 2048 -M 16'
(51 processes total). Thanks!

kamctl stats
{
  "jsonrpc":  "2.0",
  "result": [
"core:bad_URIs_rcvd = 6470677",
"core:bad_msg_hdr = 25370",
"core:drop_replies = 0",
"core:drop_requests = 342064",
"core:err_replies = 0",
"core:err_requests = 0",
"core:fwd_replies = 24367",
"core:fwd_requests = 375703",
"core:rcv_replies = 45021597",
"core:rcv_replies_18x = 834856",
"core:rcv_replies_1xx = 1505425",
"core:rcv_replies_1xx_bye = 17",
"core:rcv_replies_1xx_cancel = 7",
"core:rcv_replies_1xx_invite = 1497313",
"core:rcv_replies_1xx_message = 0",
"core:rcv_replies_1xx_prack = 0",
"core:rcv_replies_1xx_refer = 0",
"core:rcv_replies_1xx_reg = 0",
"core:rcv_replies_1xx_update = 0",
"core:rcv_replies_2xx = 41764997",
"core:rcv_replies_2xx_bye = 328464",
"core:rcv_replies_2xx_cancel = 223572",
"core:rcv_replies_2xx_invite = 371129",
"core:rcv_replies_2xx_message = 190",
"core:rcv_replies_2xx_prack = 0",
"core:rcv_replies_2xx_refer = 3205",
"core:rcv_replies_2xx_reg = 12783948",
"core:rcv_replies_2xx_update = 0",
"core:rcv_replies_3xx = 1052",
"core:rcv_replies_3xx_bye = 0",
"core:rcv_replies_3xx_cancel = 0",
"core:rcv_replies_3xx_invite = 1052",
"core:rcv_replies_3xx_message = 0",
"core:rcv_replies_3xx_prack = 0",
"core:rcv_replies_3xx_refer = 0",
"core:rcv_replies_3xx_reg = 0",
"core:rcv_replies_3xx_update = 0",
"core:rcv_replies_401 = 17120",
"core:rcv_replies_404 = 525917",
"core:rcv_replies_407 = 553",
"core:rcv_replies_480 = 23138",
"core:rcv_replies_486 = 74201",
"core:rcv_replies_4xx = 1715492",
"core:rcv_replies_4xx_bye = 2146",
"core:rcv_replies_4xx_cancel = 594",
"core:rcv_replies_4xx_invite = 317850",
"core:rcv_replies_4xx_message = 208",
"core:rcv_replies_4xx_prack = 0",
"core:rcv_replies_4xx_refer = 1",
"core:rcv_replies_4xx_reg = 2382",
"core:rcv_replies_4xx_update = 0",
"core:rcv_replies_5xx = 29462",
"core:rcv_replies_5xx_bye = 15",
"core:rcv_replies_5xx_cancel = 10",
"core:rcv_replies_5xx_invite = 3501",
"core:rcv_replies_5xx_message = 0",
"core:rcv_replies_5xx_prack = 0",
"core:rcv_replies_5xx_refer = 0",
"core:rcv_replies_5xx_reg = 25157",
"core:rcv_replies_5xx_update = 0",
"core:rcv_replies_6xx = 5169",
"core:rcv_replies_6xx_bye = 0",
"core:rcv_replies_6xx_cancel = 0",
"core:rcv_replies_6xx_invite = 5169",
"core:rcv_replies_6xx_message = 0",
"core:rcv_replies_6xx_prack = 0",
"core:rcv_replies_6xx_refer = 0",
"core:rcv_replies_6xx_reg = 0",
"core:rcv_replies_6xx_update = 0",
"core:rcv_requests = 67620661",
"core:rcv_requests_ack = 707431",
"core:rcv_requests_bye = 336874",
"core:rcv_requests_cancel = 226878",
"core:rcv_requests_info = 70",
"core:rcv_requests_invite = 1038320",
"core:rcv_requests_message = 796",
"core:rcv_requests_notify = 6027113",
"core:rcv_requests_options = 29079952",
"core:rcv_requests_prack = 0",
"core:rcv_requests_publish = 40344",
"core:rcv_requests_refer = 3217",
"core:rcv_requests_register = 20919429",
"core:rcv_requests_subscribe = 5296608",
"core:rcv_requests_update = 0",
"core:unsupported_methods = 0",
"dialog:active_dialogs = 458",
"dialog:early_dialogs = 123",
"dialog:expired_dialogs = 105",
"dialog:failed_dialogs = 321224",
"dialog:processed_dialogs = 645092",
"dns:failed_dns_request = 534",
"dns:slow_dns_request = 0",
"mysql:driver_errors = 18",
"shmem:fragments = 8836",
"shmem:free_size = 1955034032",
"shmem:max_used_size = 250791392",
"shmem:real_used_size = 192449616",
"shmem:total_size = 2147483648",
"shmem:used_size = 105997528",
"siptrace:traced_replies = 0",
"siptrace:traced_requests = 0",
"sl:1xx_replies = 0",
"sl:200_replies = 14330540",
"sl:202_replies = 0",
"sl:2xx_replies = 0",
"sl:300_replies = 0",
"sl:301_replies = 0",
"sl:302_replies = 0",

Re: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK

[George Diamantopoulos]

Not sure if this is related, but I've also run into issues with
track_cseq_updates:
https://www.mail-archive.com/sr-users@lists.kamailio.org/msg12362.html

More specifically, kamailio won't process the 100 Trying to an Cseq-bumped
INVITE it generated
itself with uac_auth() when track_cseq_updates is on.

This implementation appears to be a little too fragile for the time
being

BR,
George

On Thu, 17 Dec 2020 at 12:29, Terry Tailor  wrote:

> Hi, Here is setup details
> Kamailio Proxy a <-> Kamailio Proxy b  <-> Asterisk
> Kamailio proxy b auth based on IP Kamailio Proxy a
> 1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
> 102 INVITE
> 2. Kamailio proxy b check again IP auth and sends invite request to
> asterisk with CSeq: 102 INVITE
> 4 asterisk response with 401 Unauthorized with  CSeq: 102
> 5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
> 6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
> 7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
> 8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
> 9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to
> proxy a with CSeq: 102 INVITE
> 10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
> asterisk with CSeq: 102 ACK
>
> Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a is
> sending ACK with Cseq: 102 ACK
>
> Same happing in case of 487 Request Terminated
>
> Here is my config
>
> modparam("dialog", "default_timeout", 10800) # 3h
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "send_bye", 1)
> modparam("dialog", "track_cseq_updates", 1)
> modparam("uac","auth_username_avp","$avp(auser)")
> modparam("uac","auth_password_avp","$avp(apass)")
> modparam("uac","auth_realm_avp","$avp(arealm)")
>
> modparam("tm", "failure_reply_mode", 3)
> # default retransmission timeout: 3 sec
> modparam("tm", "fr_timer", 2000)
> modparam("tm", "retr_timer1", 250)
> modparam("tm", "retr_timer2", 500)
> # default invite retransmission timeout after 1xx: 60 sec
> modparam("tm", "fr_inv_timer", 6)
> modparam("tm", "reparse_on_dns_failover", 0)
>
>
>
> if (is_method("INVITE") && !has_totag()) {
> dlg_setflag(FLD_RTPPROXY);
> dlg_manage();
> }
> route(RELAY);
>
>
>
>
> route[RELAY] {
>
> # At this point all checks are passed
> t_on_branch("MANAGE_BRANCH");
> t_on_reply("MANAGE_REPLY");
> t_on_failure("MANAGE_FAILURE");
> if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>  #$fd = "sip.comms.kuflink.com";
>   t_on_failure("RELAY_AUTH");
> }
>
> if (!t_relay()) {
> send_reply("500", "Cannot relay to $du/$ru");
> }
> exit;
> }
>
> failure_route[RELAY_AUTH] {
> t_on_branch("MANAGE_BRANCH");
> t_on_reply("MANAGE_REPLY");
> if (t_is_canceled()) {
> exit;
> }
> if(t_check_status("401|407")) {
> #$fd = "sip.comms.kuflink.com";
> $avp(auser) = "DID_UA_USERNAME";
> $avp(apass) = "DID_UA_PASSWORD";
> if (uac_auth()) {
> t_relay();
> }
> exit;
> }
> }
>
>
> route[WITHINDLG] {
> if (!has_totag()) {
> return;
> }
>
> if (is_method("BYE")) {
> rtpengine_delete();
> }
>
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> route(DLGURI);
> if (is_method("ACK")) {
> # ACK is forwarded statelessly
> route(NATMANAGE);
> } else if (is_method("NOTIFY")) {
> # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
> record_route();
> }
> route(RELAY);
> exit;
> }
>
> if (is_method("SUBSCRIBE") && uri == myself) {
> # in-dialog subscribe requests
> route(PRESENCE);
> exit;
> }
> if (is_method("ACK") ) {
> if (t_check_trans()) {
> # no loose-route, but stateful ACK;
> # must be an ACK after a 487
> # or e.g. 404 from upstream server
> route(RELAY);
> exit;
> } else {
> # ACK without matching transaction ... ignore and discard
> exit;
> }
> }
> send_reply("404","Not here");
> exit;
> }
>
>
> kamailio -v
> version: kamailio 5.3.7 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 6.3.0
>
>
> uname 

Re: [SR-Users] Received parameter on Via

[George Diamantopoulos]

Reading your question again, I realize you weren't looking for nat advice
in general, you only wanted to know how the received parameter is added.
Well there's no special function to do this, since it's core SIP, received
is added any time a request is relayed or a local response is generated. It
is always added if different from host addr in via, regardless of nat
detection or loading of nat modules in kamailio.

On Tue, 29 Sep 2020, 03:48 George Diamantopoulos, 
wrote:

> Received parameter is always added to via, and is part of the core sip
> RFC. This is how responses are routed.
>
> To get nat traversal on kamailio, you generally need the following in
> addition:
>
> - Received only handles address masquerading, for port translation you
> also need to look at rport.
> - A way to perform nat traversal for subsequent in dialog requests, and
> additionally for initial requests involving location lookup. This is where
> nathelper or similar must be involved.
> - Prevent UDP Connection Tracking Timeout on NAT boxes (keeping nat
> alive). This can be achieved in many ways, including configuration on NATed
> devices (low registration expiration, keepalives) but it's better to employ
> keepalive functionality by kamailio modules (nathelper or usrloc ka, for
> example).
>
> The actual way to perform these tasks is a bit more involved, and I'd
> suggest looking at the kamailio sample configuration file which should work
> for most cases.
>
> On Mon, 28 Sep 2020, 19:36 Duarte Rocha,  wrote:
>
>> Greetings,
>>
>> When NAT is detected in my Kamailio, the proxy add the parameter
>> "received" to the Via header which includes the source IP.
>>
>> What is the mechanic or function responsible for this behaviour? Does it
>> come from the NATHELPER module?
>>
>> Best Regards,
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Received parameter on Via

[George Diamantopoulos]

Received parameter is always added to via, and is part of the core sip RFC.
This is how responses are routed.

To get nat traversal on kamailio, you generally need the following in
addition:

- Received only handles address masquerading, for port translation you also
need to look at rport.
- A way to perform nat traversal for subsequent in dialog requests, and
additionally for initial requests involving location lookup. This is where
nathelper or similar must be involved.
- Prevent UDP Connection Tracking Timeout on NAT boxes (keeping nat alive).
This can be achieved in many ways, including configuration on NATed devices
(low registration expiration, keepalives) but it's better to employ
keepalive functionality by kamailio modules (nathelper or usrloc ka, for
example).

The actual way to perform these tasks is a bit more involved, and I'd
suggest looking at the kamailio sample configuration file which should work
for most cases.

On Mon, 28 Sep 2020, 19:36 Duarte Rocha,  wrote:

> Greetings,
>
> When NAT is detected in my Kamailio, the proxy add the parameter
> "received" to the Via header which includes the source IP.
>
> What is the mechanic or function responsible for this behaviour? Does it
> come from the NATHELPER module?
>
> Best Regards,
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Mapping History-Info <-> Diversion headers

[George Diamantopoulos]

Hello,

I had a similar need (process/create hinfo, and briefly looked at diversion
header conversion) but there doesn't seem to be any awareness of history
info in kami modules yet.

It has been my intention to begin working on a module at some point in the
future, but my C programming skills aren't quite there yet, and I haven't
had time to devote in acquiring them.

In the meantime, I manage hinfo manually, with textops and friends (and
several while loops/htable caching/transformations etc).

Cheers,
George

On Fri, 25 Sep 2020, 10:00 Anonim Stefan,  wrote:

> Hi guys,
>
> I am trying to map all History-Info to/from Diversion headers in a given
> SIP REQUEST, based on RFC 7544.
>
> I want to ask if you are aware of any module functions that does that?
> (e.g. something like convert_history_to_diversion() and
> convert_diversion_to_history())
>
> Alternatively, I want to ask you what do you think of such module
> functions and in which module would they fit best? e.g.
> textops/tectopsx/diversion ?!
>
> Thank you,
> Stefan
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Regex in the switch statement

[George Diamantopoulos]

The example mentioned above is for integers, not for Regex.

Here's the syntax for regex matching with switch():

switch ( $var(myvar) ) {
case /"^mystring1":
// Do stuff
break;
case /"^mystring2":
// Do other stuff
break;
default:
// Default actions
}

On Mon, 17 Aug 2020 at 21:18, Ilie Soltanici  wrote:

> Yes, this way is much better than duplicating code for the same trunks.
> Thank's Alex.
>
>
> On Mon, 17 Aug 2020 at 18:49, Alex Balashov 
> wrote:
>
>> I'm not sure if it's supported, but the usual way of doing this in other
>> languages is:
>>
>> switch(expr) {
>>case CASE1:
>>case CASE2:
>>   ...
>>   break;
>>
>>case CASE3:
>>   ...
>> }
>>
>> -- Alex
>>
>> On 8/17/20 1:46 PM, Ilie Soltanici wrote:
>> > Hello,
>> >
>> > Is there any way to use Regex or 'OR/AND' operators in the switch/case
>> > statements?
>> > I've tried the following syntax but it's not working, are there any
>> > other ways to do this?
>> >
>> > switch($dlg_var(ISP)) {
>> > case"TRUNK1|TRUNK2":
>> > }
>> >
>> > Thank you.
>> >
>> >
>> >
>> > ___
>> > Kamailio (SER) - Users Mailing List
>> > sr-users@lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Topos_redis and loose_route

[George Diamantopoulos]

On an unrelated note, I forgot to ask:

Ernest, how did you obfuscate the IPs in the pcap files? Is it a feature of
wireshark I haven't discovered yet, or some other tool? Thanks!

On Mon, 14 Sep 2020 at 23:07, George Diamantopoulos 
wrote:

> Hello all,
>
> I believe I'm also affected by this on kamailio 5.4.1
>
> loose_route() returns false for in-dialog SUBSCRIBE
>
> The issue does not manifest with topos disabled for SUBSCRIBEs (using the
> appropriate event_route)
>
> Daniel, I can provide PCAPs privately if needed. Thank you.
>
> Best regards.
> George
>
> On Tue, 28 Apr 2020 at 14:04, Ernest Mavrel 
> wrote:
>
>> Hi,
>>
>> Is there any findings on the issue bellow?
>> Thank you
>>
>> Kind Regards
>>
>> Ernest Mavrel je 14. 04. 20 ob 21:00 napisal:
>>
>> Hi,
>>
>> In attach pcap file.
>>
>> Kind Regards
>> Ernest Mavrel
>>
>> Daniel-Constantin Mierla je 14. 04. 20 ob 12:20 napisal:
>>
>> Hello,
>>
>> can you resent the sip traffic as a pcap file? The PCAP.txt is a text
>> export, probably done with wireshark, but that is harder to analyze. Pcap
>> format is better, can be opened again with wireshark, ngrep, etc... and
>> generate message flows locally.
>>
>> Cheers,
>> Daniel
>> On 14.04.20 11:10, Ernest Mavrel wrote:
>>
>> Dear Community,
>>
>> I forgot to mention that loose_route return false on PRACK message and
>> consequently Kamailio return 404 Not Found as defined in configuration.
>>
>> Kind Regards
>> Ernest Mavrel
>>
>> Ernest Mavrel je 10. 04. 20 ob 09:48 napisal:
>>
>> Dear Community,
>>
>> Call scenario:
>>
>> Calling number33825462354
>> Called number44656646820
>>
>> UAC (IP=1.1.1.1) => Kamailio (IP=2.2.2.2) => SIP proxy (IP=3.3.3.3)
>>
>> I stocked on strange issue with module TOPOS_REDIS and PRACK message
>> (IP=2.2.2.2 kamailio version 5.2.3).
>>
>> Configuration with module TOPOS works, but because of a lot of calls we
>> would like to use TOPOS_REDIS (avoid mysql).
>>
>> I already check this:
>> https://lists.kamailio.org/pipermail/sr-users/2018-May/101641.html and I
>> already have fixed version of module.
>>
>> In attach you can find traces (pcap file and kamailio log with debug=4)
>>
>> Your help will be greatly appreciated
>>
>>
>> Kind Regards
>>
>> Ernest Mavrel
>>
>> ___
>> Kamailio (SER) - Users Mailing 
>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing 
>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
>> www.linkedin.com/in/miconda
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Topos_redis and loose_route

[George Diamantopoulos]

Hello all,

I believe I'm also affected by this on kamailio 5.4.1

loose_route() returns false for in-dialog SUBSCRIBE

The issue does not manifest with topos disabled for SUBSCRIBEs (using the
appropriate event_route)

Daniel, I can provide PCAPs privately if needed. Thank you.

Best regards.
George

On Tue, 28 Apr 2020 at 14:04, Ernest Mavrel 
wrote:

> Hi,
>
> Is there any findings on the issue bellow?
> Thank you
>
> Kind Regards
>
> Ernest Mavrel je 14. 04. 20 ob 21:00 napisal:
>
> Hi,
>
> In attach pcap file.
>
> Kind Regards
> Ernest Mavrel
>
> Daniel-Constantin Mierla je 14. 04. 20 ob 12:20 napisal:
>
> Hello,
>
> can you resent the sip traffic as a pcap file? The PCAP.txt is a text
> export, probably done with wireshark, but that is harder to analyze. Pcap
> format is better, can be opened again with wireshark, ngrep, etc... and
> generate message flows locally.
>
> Cheers,
> Daniel
> On 14.04.20 11:10, Ernest Mavrel wrote:
>
> Dear Community,
>
> I forgot to mention that loose_route return false on PRACK message and
> consequently Kamailio return 404 Not Found as defined in configuration.
>
> Kind Regards
> Ernest Mavrel
>
> Ernest Mavrel je 10. 04. 20 ob 09:48 napisal:
>
> Dear Community,
>
> Call scenario:
>
> Calling number33825462354
> Called number44656646820
>
> UAC (IP=1.1.1.1) => Kamailio (IP=2.2.2.2) => SIP proxy (IP=3.3.3.3)
>
> I stocked on strange issue with module TOPOS_REDIS and PRACK message
> (IP=2.2.2.2 kamailio version 5.2.3).
>
> Configuration with module TOPOS works, but because of a lot of calls we
> would like to use TOPOS_REDIS (avoid mysql).
>
> I already check this:
> https://lists.kamailio.org/pipermail/sr-users/2018-May/101641.html and I
> already have fixed version of module.
>
> In attach you can find traces (pcap file and kamailio log with debug=4)
>
> Your help will be greatly appreciated
>
>
> Kind Regards
>
> Ernest Mavrel
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello Daniel,

I have forwarded the requested capture files to your private email address.
Thanks!

Best regards,
George

On Wed, 8 Jul 2020 at 13:06, Daniel-Constantin Mierla 
wrote:

> Can you send the pcap taken on kamailio server for such call (with all
> request/replies)?
>
> Cheers,
> Daniel
> On 08.07.20 11:49, George Diamantopoulos wrote:
>
> Update: Disabling the topoh module on the proxy which produces the error
> seems to stop the failure from manifesting. I'll try using topos_redis
> instead, but should this be treated as a bug?
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 12:37, George Diamantopoulos 
> wrote:
>
>> Hello again,
>>
>> Indeed $mb seems to contain garbage:
>>
>> SCRIPT_MB: ACK <8F> SIP/2.0#015#012Via: SIP/2.0/UDP
>> 172.30.154.189;TH=dcv;branch=z9hG4bK629b.6af9302cd78dc58dffe817e60124f4ed.0#015#012Route:
>> > sip:2.2.2.2:32768;ob;r2=on>,> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>#015#012Max-Forwards:
>> 68#015#012From: "Anonymous" 
>> ;tag=as4bc9e324#015#012To:
>> ;tag=jw7z5s0zvc#015#012Call-ID:
>> 0138c6370346d1dd7f1b47f604b01...@voip.domain.com#015#012CSeq
>> <http://0138c6370346d1dd7f1b47f604b01...@voip.domain.com#015%23012CSeq>:
>> 102 ACK#015#012Content-Length: 0#015#012TH: dch#015#012#015#012
>>
>> How can this be possible? Capturing traffic on wire shows the RURI I
>> pasted in my original message and there are no script operations on the
>> RURI before sanity_check() (message buffer above is printed just before
>> sanity_check() is run in REQINIT).
>>
>> BR,
>> George
>>
>> On Wed, 8 Jul 2020 at 11:18, George Diamantopoulos 
>> wrote:
>>
>>> I'll post the message buffer ASAP, but in the meantime I don't see how
>>> config operations could affect the RURI. Here's everything that's happening
>>> until the sanity check involved:
>>>
>>> request_route {
>>>
>>> if(is_method("KDMQ")) {
>>> dmq_handle_message();
>>> }
>>>
>>> # no connect for sending replies
>>> set_reply_no_connect();
>>>
>>> if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
>>> # silent drop for scanners - uncomment next line if want to reply
>>> # sl_send_reply("200", "OK");
>>> exit;
>>> }
>>>
>>> if (!mf_process_maxfwd_header("10")) {
>>> force_rport();
>>> sl_send_reply("483","Too Many Hops");
>>> exit;
>>> }
>>>
>>> # OPTIONS and NOTIFYs directed to myself
>>> if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
>>> force_rport();
>>> sl_send_reply("200","Keepalive");
>>> exit;
>>> }
>>>
>>> # All keep-alive methods regardless of destination
>>> if ( $hdr(Event) == "keep-alive") {
>>> force_rport();
>>> sl_send_reply("200","Keepalive");
>>> exit;
>>> }
>>>
>>> if(!sanity_check("17895", "7")) {
>>> xlog("Malformed SIP request from $si:$sp\n");
>>> exit;
>>> }
>>>
>>> BR,
>>> George
>>>
>>> On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> check your config operations, because the R-URI seems to be the next
>>>> string (without quotes): "<8F>"
>>>>
>>>> You can try to print $mb in such case to see the entire SIP message
>>>> buffer.
>>>>
>>>> Cheers,
>>>> Daniel
>>>> On 08.07.20 09:48, George Diamantopoulos wrote:
>>>>
>>>> Hello Daniel,
>>>>
>>>> Thanks for the reply. Indeed there is, not sure how I managed to miss
>>>> that. And it wasn't about the schema after all:
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
>>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
>>>> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
>>>> (3)
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
>>>> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
>>>> [sanity.c:282]: check_ruri_scheme(): failed to parse request uri
>>>> [<8F>]
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
>>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>>>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR:
>>>> {1  172.30.154.189 102 ACK
>>>> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

I'll post the message buffer ASAP, but in the meantime I don't see how
config operations could affect the RURI. Here's everything that's happening
until the sanity check involved:

request_route {

if(is_method("KDMQ")) {
dmq_handle_message();
}

# no connect for sending replies
set_reply_no_connect();

if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
# silent drop for scanners - uncomment next line if want to reply
# sl_send_reply("200", "OK");
exit;
}

if (!mf_process_maxfwd_header("10")) {
force_rport();
sl_send_reply("483","Too Many Hops");
exit;
}

# OPTIONS and NOTIFYs directed to myself
if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
force_rport();
sl_send_reply("200","Keepalive");
exit;
}

# All keep-alive methods regardless of destination
if ( $hdr(Event) == "keep-alive") {
force_rport();
sl_send_reply("200","Keepalive");
exit;
}

if(!sanity_check("17895", "7")) {
xlog("Malformed SIP request from $si:$sp\n");
exit;
}

BR,
George

On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> check your config operations, because the R-URI seems to be the next
> string (without quotes): "<8F>"
>
> You can try to print $mb in such case to see the entire SIP message buffer.
>
> Cheers,
> Daniel
> On 08.07.20 09:48, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> Thanks for the reply. Indeed there is, not sure how I managed to miss
> that. And it wasn't about the schema after all:
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
> check_ruri_scheme(): check_ruri_scheme entered
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
> (3)
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:282]:
> check_ruri_scheme(): failed to parse request uri [<8F>]
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello Daniel,

Thanks for the reply. Indeed there is, not sure how I managed to miss that.
And it wasn't about the schema after all:
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
[core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
(3)
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
[core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:282]:
check_ruri_scheme(): failed to parse request uri [<8F>]
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Sorry, I realised I copy pasted wrong log messages for Call 1. Here's the
relevant part showing success for call 1 in contrast with Call 2:

grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep
'check_ruri_scheme|w_sanity_check' | grep ACK
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:297]:
check_ruri_scheme(): check_ruri_scheme passed
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1

On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos 
wrote:

> Hello all,
>
> I'm not 100% sure this is the only culprit in an issue I'm investigating,
> but superficially it appears that RURI scheme sanity module checks from the
> default config (flags 17895 in REQINIT) fail if the RURI in an ACK
> following a 487 includes parameters. Example from two calls from a kamailio
> instance acting as registrar/usrloc server, INVITE RURIs are after usrloc
> lookup:
>
> Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
> Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
> SIP/2.0
>
> These INVITEs produce no complaints. Later, the same registrar produces
> ACKs to acknowledge 487 (thus, same transaction ACKs) responses from the
> next proxy in the path following a CANCEL:
>
> Call 1: ACK sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
> Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0
>
> The next proxy (which produced/relayed the 487) processes the ACK for Call
> 1 successfully, but sanity_check at the proxy drops the request for Call 2
> with:
>
> DEBUG: {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
> check_ruri_scheme(): check_ruri_scheme entered
> DEBUG: {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>
> whereas Call 1 seems OK:
>
> DEBUG: {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:305]:
> check_required_headers(): check_required_headers entered
> DEBUG: {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:313]:
> check_required_headers(): check_required_headers passed
>
> Could this be a bug in sanity module? Is there anything one can do in
> config which could result in illegal ACKs being produced for hop-by-hop
> transactions? schema appears to be sip: in both cases...
>
> Thank you. Best regards,
> George
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello all,

I'm not 100% sure this is the only culprit in an issue I'm investigating,
but superficially it appears that RURI scheme sanity module checks from the
default config (flags 17895 in REQINIT) fail if the RURI in an ACK
following a 487 includes parameters. Example from two calls from a kamailio
instance acting as registrar/usrloc server, INVITE RURIs are after usrloc
lookup:

Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0

These INVITEs produce no complaints. Later, the same registrar produces
ACKs to acknowledge 487 (thus, same transaction ACKs) responses from the
next proxy in the path following a CANCEL:

Call 1: ACK sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0

The next proxy (which produced/relayed the 487) processes the ACK for Call
1 successfully, but sanity_check at the proxy drops the request for Call 2
with:

DEBUG: {1  172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
DEBUG: {1  172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0

whereas Call 1 seems OK:

DEBUG: {1  172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:305]:
check_required_headers(): check_required_headers entered
DEBUG: {1  172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:313]:
check_required_headers(): check_required_headers passed

Could this be a bug in sanity module? Is there anything one can do in
config which could result in illegal ACKs being produced for hop-by-hop
transactions? schema appears to be sip: in both cases...

Thank you. Best regards,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog's track_cseq_updates seems to break uac_auth() in this configuration

[George Diamantopoulos]

Hello Daniel,

Thank you for the reply. Sure, I'll send one to your private email address.
Thanks!

BR,
George

On Wed, 24 Jun 2020 at 12:06, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> can you send a pcap with a call reproducing such case? I can check it with
> the c code and see if something is mismatched.
>
> Cheers,
> Daniel
> On 09.06.20 13:00, George Diamantopoulos wrote:
>
> Hello again,
>
> This might turn out to be a bug, but I'm posting here first because my
> config is fairly complicated and it might not be the sanest it could be.
> The problem manifests as follows: with the sole change being the enabling
> of track_cseq_updates for the dialog module, kamailio fails to process the
> 100 Trying it receives following authentication initiated by the uac_auth()
> function. Without the track_cseq_updates option enabled, the call proceeds
> successfully, albeit with the CSeq for the auth-carrying INVITE having the
> same value as the original.
>
> Here's a simplified version of the configuration routes involved in this:
>
> request_route {
> ...
> route(DISPATCH_PROVIDER);
> ...
> }
>
> route[DISPATCH_PROVIDER] {
> if ( !ds_select_dst("10", "8") ) {
> t_send_reply("503", "Downstream carrier unavailable");
> exit;
> }
>
> t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
> t_on_branch("PROVIDER_BRANCH");
> t_on_failure("DISPATCH_PROVIDER_FAILURE");
>
> route(RELAY);
> exit;
> }
>
> failure_route[DISPATCH_PROVIDER_FAILURE] {
> if (t_is_canceled()) {
> exit;
> }
> if ( t_check_status("401|407") ) {
> $avp(arealm) = "authrealm.com";
> $avp(auser) = "authusername";
> $avp(apass) = "verys3kr1t";
> uac_auth();
>
> t_on_branch("PROVIDER_BRANCH");
> t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
> t_on_failure("DISPATCH_PROVIDER_FAILURE");
>
> $du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp); // I'll explain
> why this is here later in this e-mail
> t_relay();
> exit;
> }
> }
>
> branch_route[PROVIDER_BRANCH] {
> uac_replace_from("$dlg_var(my_new_from)");
> uac_replace_to("$dlg_var(my_new_to)");
> $rU = "my new RURI user";
> }
>
> event_route[tm:branch-failure:DISPATCH_PROVIDER_FAILOVER] {
> if (t_is_canceled()) {
> exit;
> }
> if ( t_check_status("401|407") ) {
> return;
> # next DST - only for 5xx or local timeout
> } else if ( t_check_status("5[0-9][0-9]") || (t_branch_timeout() &&
> !t_branch_replied()) ) {
> if ( ds_next_dst() ) {
> t_on_branch("PROVIDER_BRANCH");
> t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
> t_on_failure("DISPATCH_PROVIDER_FAILURE");
> route(RELAY);
> exit;
> } else {
> xlog("L_NOTICE", "--- SCRIPT_DISPATCH_PROVIDER_FAILOVER:
> Failed to route request to PROVIDER! Giving Up. Negative response will be
> sent upstream.\n");
> }
> }
> }
>
> One will rightfully wonder why use both branch-failure routes and
> failure_route to handle things. Well, it's not obvious from this because
> the relevant parts are removed for brevity, but I'm generally using branch
> failure event routes to try other destinations in the same destination set,
> and failure routes to additionally try other downstream "providers" in case
> all entries is the current destination set have failed. I don't think these
> actions/routes are relevant because the problem manifests without any of
> these failover mechanisms (of switching over to the next provider) engaging.
>
> Regarding the line "$du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp);" in
> the failure_route, which might seem a little odd, this was added because
> without it, uac_auth() will send the auth-carrying INVITE always to the
> first destination in the destination set even if ds_next_dst has been
> called from the branch-failure event route. Unfortunately I haven't been
> able to determine if this actually helped, because I have only received a
> 5xx error once from the downstream peer before the "fix" and haven't been
> able to reproduce this since then. But that's another issue unrelated to
> the one I'm asking about here.
>
> So what happens with track_cseq_updates enabled is, after uac_auth()
>

[SR-Users] dialog's track_cseq_updates seems to break uac_auth() in this configuration

[George Diamantopoulos]

Hello again,

This might turn out to be a bug, but I'm posting here first because my
config is fairly complicated and it might not be the sanest it could be.
The problem manifests as follows: with the sole change being the enabling
of track_cseq_updates for the dialog module, kamailio fails to process the
100 Trying it receives following authentication initiated by the uac_auth()
function. Without the track_cseq_updates option enabled, the call proceeds
successfully, albeit with the CSeq for the auth-carrying INVITE having the
same value as the original.

Here's a simplified version of the configuration routes involved in this:

request_route {
...
route(DISPATCH_PROVIDER);
...
}

route[DISPATCH_PROVIDER] {
if ( !ds_select_dst("10", "8") ) {
t_send_reply("503", "Downstream carrier unavailable");
exit;
}

t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
t_on_branch("PROVIDER_BRANCH");
t_on_failure("DISPATCH_PROVIDER_FAILURE");

route(RELAY);
exit;
}

failure_route[DISPATCH_PROVIDER_FAILURE] {
if (t_is_canceled()) {
exit;
}
if ( t_check_status("401|407") ) {
$avp(arealm) = "authrealm.com";
$avp(auser) = "authusername";
$avp(apass) = "verys3kr1t";
uac_auth();

t_on_branch("PROVIDER_BRANCH");
t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
t_on_failure("DISPATCH_PROVIDER_FAILURE");

$du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp); // I'll explain why
this is here later in this e-mail
t_relay();
exit;
}
}

branch_route[PROVIDER_BRANCH] {
uac_replace_from("$dlg_var(my_new_from)");
uac_replace_to("$dlg_var(my_new_to)");
$rU = "my new RURI user";
}

event_route[tm:branch-failure:DISPATCH_PROVIDER_FAILOVER] {
if (t_is_canceled()) {
exit;
}
if ( t_check_status("401|407") ) {
return;
# next DST - only for 5xx or local timeout
} else if ( t_check_status("5[0-9][0-9]") || (t_branch_timeout() &&
!t_branch_replied()) ) {
if ( ds_next_dst() ) {
t_on_branch("PROVIDER_BRANCH");
t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
t_on_failure("DISPATCH_PROVIDER_FAILURE");
route(RELAY);
exit;
} else {
xlog("L_NOTICE", "--- SCRIPT_DISPATCH_PROVIDER_FAILOVER: Failed
to route request to PROVIDER! Giving Up. Negative response will be sent
upstream.\n");
}
}
}

One will rightfully wonder why use both branch-failure routes and
failure_route to handle things. Well, it's not obvious from this because
the relevant parts are removed for brevity, but I'm generally using branch
failure event routes to try other destinations in the same destination set,
and failure routes to additionally try other downstream "providers" in case
all entries is the current destination set have failed. I don't think these
actions/routes are relevant because the problem manifests without any of
these failover mechanisms (of switching over to the next provider) engaging.

Regarding the line "$du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp);" in the
failure_route, which might seem a little odd, this was added because
without it, uac_auth() will send the auth-carrying INVITE always to the
first destination in the destination set even if ds_next_dst has been
called from the branch-failure event route. Unfortunately I haven't been
able to determine if this actually helped, because I have only received a
5xx error once from the downstream peer before the "fix" and haven't been
able to reproduce this since then. But that's another issue unrelated to
the one I'm asking about here.

So what happens with track_cseq_updates enabled is, after uac_auth()
successfully sends the authenticated INVITE and the peer starts sending
provisional responses, kamailio doesn't seem to acknowledge them. Instead,
it will retransmit the auth INVITE as if there was a firewall preventing
the 1xx responses from being admitted. Then, the timeout will engage and
the configuration script will behave as if t_branch_timeout returns true
(it will do ds_next_dst).

So I was wondering if this is to be expected with this configuration, or if
this should be reported as a bug. Thanks!

Best regards,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Does DMQ auto-discover cluster members + how?

[George Diamantopoulos]

Hello all,

Thank you for your replies. Indeed, it seems that at some point one of the
staging instances was started with the production hostname for DMQ, which
then propagated to all the rest. I stopped all staging instances and after
starting them again, it appears that there are no entries for staging
instances in production kamailio DMQ lists (I restarted production
instances sequentially as well while staging instances were down).

Best regards,
George

On Wed, 3 Jun 2020 at 21:05, Alex Balashov 
wrote:

> It sounds to me like these discovered nodes are DMQ adjacencies of
> another DMQ node that _is_ properly a member of the production DMQ cluster.
>
> On 6/3/20 2:01 PM, Henning Westerholt wrote:
> > Hello George,
> >
> > In generally this should not happen. Have you already tried to restart
> > the DMQ nodes?
> >
> > You are not using a DNS record to populate the cluster members?
> >
> > Cheers,
> >
> > Henning
> >
> > --
> >
> > Henning Westerholt – https://skalatan.de/blog/
> >
> > Kamailio services – https://gilawa.com <https://gilawa.com/>
> >
> > *From:* sr-users  *On Behalf Of
> > *George Diamantopoulos
> > *Sent:* Wednesday, June 3, 2020 6:29 PM
> > *To:* Kamailio (SER) - Users Mailing List 
> > *Subject:* [SR-Users] Does DMQ auto-discover cluster members + how?
> >
> > Hello all (again),
> >
> > When running dmq.list_nodes on one of my production kamailio servers, I
> > get several entries corresponding to staging instances of kamailio.
> > These staging instances are located on separate broadcast domains
> > (different VLANs), and none of them are configured in the
> > notification_address parameter for the dmq module.
> >
> > How do they end up there, and how do I get rid of them?
> >
> > Thanks!
> >
> > George
> >
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Does DMQ auto-discover cluster members + how?

[George Diamantopoulos]

Hello all (again),

When running dmq.list_nodes on one of my production kamailio servers, I get
several entries corresponding to staging instances of kamailio. These
staging instances are located on separate broadcast domains (different
VLANs), and none of them are configured in the notification_address
parameter for the dmq module.

How do they end up there, and how do I get rid of them?

Thanks!
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamcmd mtree.match

[George Diamantopoulos]

Have you tried

kamcmd mtree.match siteId s:49241531075212 0

?
On Tue, 2 Jun 2020, 17:17 Henning Westerholt,  wrote:

> Hello Volker,
>
>
>
> the error message you‘ve got from the command looks like the generic error
> that is returned if the number or type of parameters do not match. Did you
> managed to get a match from the kamcmd command at all?
>
>
>
> Further hints might be also visible in the kamailio log file.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *Volker
> Denneberg
> *Sent:* Sunday, May 31, 2020 12:03 AM
> *To:* sr-users@lists.kamailio.org
> *Subject:* [SR-Users] kamcmd mtree.match
>
>
>
> Hi,
>
>
>
> given this mtree
>
>
>
> kamcmd mtree.list siteId
>
> {
>
> tname: siteId
>
> tprefix: 00492419697994
>
> tvalue: {
>
> 00492419697994 2388
>
> }
>
> }
>
> {
>
> tname: siteId
>
> tprefix: 492415310752
>
> tvalue: {
>
> 492415310752 2388
>
> }
>
> }
>
>
>
> i wonder why this lookup fails:
>
>
>
> kamcmd mtree.match siteId 49241531075212 0
>
> error: 500 - Invalid Parameters
>
>
>
> My expectation was that 2nd tprefix should match.
>
>
>
> I am using
>
>
>
> modparam("mtree", "db_table", "mtrees")
>
> modparam("mtree", "char_list", "0123456789+")
>
> modparam("mtree", "mt_tree_type", 0)# payload type for
> tree data : string
>
>
>
> Thanks in advance,
>
> Volker
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Meaning of shmem stats and question on dmq dialog sharing behaviour

[George Diamantopoulos]

Nope, it opens fine here. Does this work: https://snipboard.io/5E4V3m.jpg ?

On Tue, 2 Jun 2020 at 08:34, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> I get image not found on that link, have you removed it?
>
> Cheers,
> Daniel
> On 01.06.20 13:57, George Diamantopoulos wrote:
>
> Hello all,
>
> I've recently been experimenting with dmq, and I've noticed something that
> seemed a little odd. shmem use would often be abnormally high on otherwise
> idle kamailio nodes (literally, only dispatcher module OPTIONS were
> exchanged at the time besides KDMQ messages).
>
> After disabling the "enable_dmq" parameter for the dialog module, this
> sort of absurd behaviour ceased. To get a quantified idea of this change's
> effect, check out the following screenshot from our monitoring system:
> https://pasteboard.co/Jb430lD.png
>
> As you can see, the spikes stopped manifesting at around 05:00, when dmq
> was disabled for dialog (albeit still employed for htable). shmem use then
> grew as traffic was introduced to these nodes, and htables began filling
> with data.
>
> I was wondering if this to be expected, which I find highly odd given that
> at the time other productive systems in the DMQ cluster were also idle
> (given the time of the day), not to mention that their shmem usage was not
> nearly as high.
>
> Could this be attributed to some configuration error, with updates looping
> endlessly (or until some counter reaches zero or something) among nodes? Or
> could memory be used for other housekeeping purposes unrelated to dmq
> dialog sharing?
>
> Lastly, what is the meaning (and differences) of these shmem stats?
>
>- real_used_size
>- used_size
>- max_used_size
>
> Max used size I get (I'm guessing maximum seen since server was started?)
> but what's the difference between real_used and used? Thanks!
>
> Best regards,
> George
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation

[George Diamantopoulos]

Daniel, that worked instantly, thank you!

Care to elaborate on how msg_apply_changes() interferes with loose_route? I
also remember msg_apply_changes() complaining if called after
record_route(), is it related?

On Mon, 1 Jun 2020 at 21:24, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> use msg_apply_changes just after replace_body_str(), eventually before
> loose routing processing for requests within dialog.
>
> Cheers,
> Daniel
> On 01.06.20 13:34, George Diamantopoulos wrote:
>
> Hello all,
>
> I'm facing one of those cases where I need to edit the body of a SIP
> message, which is then to be fed to rtpengine for processing. Although I've
> taken every precaution I've read about on this list and elsewhere, I can't
> prevent the edited line from appearing twice in the outgoing message.
>
> The configuration file used is huge, so I'm going to try to provide a
> high-level overview here. But first, the things (I think) I know to be
> requirements, and which I have striven to meet:
>
>- If SDP is to be edited, then all such processing is to be carried
>out in such a way in the script, so that msg_apply_changes() is run as many
>times as needed before rtpengine offer/answer/manage is called.
>- rtpengine offer/answer/manage is to be called only once per script
>iteration
>- msg_apply_changes can only be called in a request route, or in the
>core reply_route (i.e. *not* in tm-managed on_reply_route[XXX] blocks)
>
> In my case, additionally the following are true:
>
>- SDP processing (other than the one performed by rtpengine) takes
>place in one common route for all cases where it needs to happen. These are
>two at the moment in my scenario:
>- Early in the WITHINDLG route (of the example config file)
>   - After the sanity checks in the reply_route (of the example config
>   file)
>- msg_apply changes() is called once, for each script iteration:
>   - right before rtpengine_manage() is called, provided that
>   t_is_request_route() returns true (so that I don't accidentally call it
>   from a branch route or anything)
>  - rtpengine_manage() is called in its own route, which is very
>  similar to the example config file's "NATMANAGE" route. Since 
> NATMANAGE is
>  called in all branch and on_reply_routes, I employ 
> t_is_request_route()
>  here to make sure it won't execute in those cases.
>   - at the end of the "core" reply_route
>
> Now regarding the actual config-file-controlled SDP manipulation, it only
> consists of a single call to replace_body_str(). The purpose is to edit a
> line in the message body from something like:
>
>- a=fmtp:101 0-16
>
> to something along the lines of:
>
>- a=fmtp:101 0-15
>
> For replies, this works as expected.
>
> For in-dialog requests, however, I end up with both the original and the
> edited lines:
> a=fmtp:101 0-16 (the original line)
> ... other SDP stuff ...
> a=fmtp:101 0-15 (the edited line)
>
> If anyone could point out any misconceptions I have about
> msg_apply_changes, SDP rewriting from the script and rtp_engine_X()
> interoperability, I would be more than grateful.
>
> Thank you in advance and I apologize for the long read.
>
> Best regards,
> George Diamantopoulos
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation

[George Diamantopoulos]

Hello Alex,

Thank you for your reply. Well, I'm interfacing with several PSTN
operators, and some of their networks' SIP endpoints (or other obscure IMS
entity there) are very picky in that if they don't like the capabilities
you serve for telephone-event (which is if they don't match theirs), then
the transaction is rejected with "488 SDP Parameter Error In SIP Request"
(or if it's a reply I'm sending, they will send a BYE immediately).

Trying to reason with them (the operators) has failed, my SIP UA provides
no way to choose these values when the SDP is created (and since it
apparently has to match the other side some static configuration wouldn't
do much here), so all I'm left with is the option of growing my config file
by yet another 50 lines... :-\

BR,
George

On Mon, 1 Jun 2020 at 14:41, Alex Balashov 
wrote:

> George,
>
> It may be orthogonal to the answer that you seek, but I’m going to ask
> anyway: what is the overall motive underlying your SDP manipulation?
>
> It seems to me that one should reason backward from that root cause. The
> kind of SDP manipulation you are doing is seldom necessary in ordinarily
> imaginable contexts...
>
> — Alex
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> On Jun 1, 2020, at 7:35 AM, George Diamantopoulos 
> wrote:
>
> 
> Hello all,
>
> I'm facing one of those cases where I need to edit the body of a SIP
> message, which is then to be fed to rtpengine for processing. Although I've
> taken every precaution I've read about on this list and elsewhere, I can't
> prevent the edited line from appearing twice in the outgoing message.
>
> The configuration file used is huge, so I'm going to try to provide a
> high-level overview here. But first, the things (I think) I know to be
> requirements, and which I have striven to meet:
>
>- If SDP is to be edited, then all such processing is to be carried
>out in such a way in the script, so that msg_apply_changes() is run as many
>times as needed before rtpengine offer/answer/manage is called.
>- rtpengine offer/answer/manage is to be called only once per script
>iteration
>- msg_apply_changes can only be called in a request route, or in the
>core reply_route (i.e. *not* in tm-managed on_reply_route[XXX] blocks)
>
> In my case, additionally the following are true:
>
>- SDP processing (other than the one performed by rtpengine) takes
>place in one common route for all cases where it needs to happen. These are
>two at the moment in my scenario:
>- Early in the WITHINDLG route (of the example config file)
>   - After the sanity checks in the reply_route (of the example config
>   file)
>- msg_apply changes() is called once, for each script iteration:
>   - right before rtpengine_manage() is called, provided that
>   t_is_request_route() returns true (so that I don't accidentally call it
>   from a branch route or anything)
>  - rtpengine_manage() is called in its own route, which is very
>  similar to the example config file's "NATMANAGE" route. Since 
> NATMANAGE is
>  called in all branch and on_reply_routes, I employ 
> t_is_request_route()
>  here to make sure it won't execute in those cases.
>   - at the end of the "core" reply_route
>
> Now regarding the actual config-file-controlled SDP manipulation, it only
> consists of a single call to replace_body_str(). The purpose is to edit a
> line in the message body from something like:
>
>- a=fmtp:101 0-16
>
> to something along the lines of:
>
>- a=fmtp:101 0-15
>
> For replies, this works as expected.
>
> For in-dialog requests, however, I end up with both the original and the
> edited lines:
> a=fmtp:101 0-16 (the original line)
> ... other SDP stuff ...
> a=fmtp:101 0-15 (the edited line)
>
> If anyone could point out any misconceptions I have about
> msg_apply_changes, SDP rewriting from the script and rtp_engine_X()
> interoperability, I would be more than grateful.
>
> Thank you in advance and I apologize for the long read.
>
> Best regards,
> George Diamantopoulos
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Meaning of shmem stats and question on dmq dialog sharing behaviour

[George Diamantopoulos]

Hello all,

I've recently been experimenting with dmq, and I've noticed something that
seemed a little odd. shmem use would often be abnormally high on otherwise
idle kamailio nodes (literally, only dispatcher module OPTIONS were
exchanged at the time besides KDMQ messages).

After disabling the "enable_dmq" parameter for the dialog module, this sort
of absurd behaviour ceased. To get a quantified idea of this change's
effect, check out the following screenshot from our monitoring system:
https://pasteboard.co/Jb430lD.png

As you can see, the spikes stopped manifesting at around 05:00, when dmq
was disabled for dialog (albeit still employed for htable). shmem use then
grew as traffic was introduced to these nodes, and htables began filling
with data.

I was wondering if this to be expected, which I find highly odd given that
at the time other productive systems in the DMQ cluster were also idle
(given the time of the day), not to mention that their shmem usage was not
nearly as high.

Could this be attributed to some configuration error, with updates looping
endlessly (or until some counter reaches zero or something) among nodes? Or
could memory be used for other housekeeping purposes unrelated to dmq
dialog sharing?

Lastly, what is the meaning (and differences) of these shmem stats?

   - real_used_size
   - used_size
   - max_used_size

Max used size I get (I'm guessing maximum seen since server was started?)
but what's the difference between real_used and used? Thanks!

Best regards,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation

[George Diamantopoulos]

Hello all,

I'm facing one of those cases where I need to edit the body of a SIP
message, which is then to be fed to rtpengine for processing. Although I've
taken every precaution I've read about on this list and elsewhere, I can't
prevent the edited line from appearing twice in the outgoing message.

The configuration file used is huge, so I'm going to try to provide a
high-level overview here. But first, the things (I think) I know to be
requirements, and which I have striven to meet:

   - If SDP is to be edited, then all such processing is to be carried out
   in such a way in the script, so that msg_apply_changes() is run as many
   times as needed before rtpengine offer/answer/manage is called.
   - rtpengine offer/answer/manage is to be called only once per script
   iteration
   - msg_apply_changes can only be called in a request route, or in the
   core reply_route (i.e. *not* in tm-managed on_reply_route[XXX] blocks)

In my case, additionally the following are true:

   - SDP processing (other than the one performed by rtpengine) takes place
   in one common route for all cases where it needs to happen. These are two
   at the moment in my scenario:
   - Early in the WITHINDLG route (of the example config file)
  - After the sanity checks in the reply_route (of the example config
  file)
   - msg_apply changes() is called once, for each script iteration:
  - right before rtpengine_manage() is called, provided that
  t_is_request_route() returns true (so that I don't accidentally call it
  from a branch route or anything)
 - rtpengine_manage() is called in its own route, which is very
 similar to the example config file's "NATMANAGE" route. Since
NATMANAGE is
 called in all branch and on_reply_routes, I employ
t_is_request_route()
 here to make sure it won't execute in those cases.
  - at the end of the "core" reply_route

Now regarding the actual config-file-controlled SDP manipulation, it only
consists of a single call to replace_body_str(). The purpose is to edit a
line in the message body from something like:

   - a=fmtp:101 0-16

to something along the lines of:

   - a=fmtp:101 0-15

For replies, this works as expected.

For in-dialog requests, however, I end up with both the original and the
edited lines:
a=fmtp:101 0-16 (the original line)
... other SDP stuff ...
a=fmtp:101 0-15 (the edited line)

If anyone could point out any misconceptions I have about
msg_apply_changes, SDP rewriting from the script and rtp_engine_X()
interoperability, I would be more than grateful.

Thank you in advance and I apologize for the long read.

Best regards,
George Diamantopoulos
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to ensure separate kamailio instances dispatchers make the same decision?

[George Diamantopoulos]

Thank you for your reply Karsten,

The distinction between the auto-incremented IDs and the manually-chosen
setid is clear to me. The issue is how to pick the same entry from the same
setid when a pvar resolves to the same value in an algorithm that takes
said pvar into account for a hash:

Say KamA has:

set_id_100_members:
 * id: 0, setid: 100, destination: sip:b2b1.domain.com...
 * id: 1, setid: 100, destination: sip:b2b2.domain.com...

and KamB has:

 * id: 7, setid: 100, destination: sip:b2b1.domain.com...
 * id: 9, setid: 100, destination: sip:b2b1.domain.com...

Now, say that $fU is used as the value to be hashed over for dispatcher.
How does one ensure that for $fU = 'alice', both KamA and KamB will choose
the same destination, for example b2b2.domain.com

Obviously, both need to be configured with setid 100, but do other things
play a role, such as the way the destination is presented (e.g. sip:
b2b2.domain.com;xdesc=b2b-east might refer to the same host as sip:
b2b2.domain.com or sip:3.3.3.3, but does it affect dispatcher in any way)?
Similarly, how about the fact that these dispatcher destinations are in
reversed order, or that their auto-increment IDs are different?

I hope this clarifies my question. Thanks!

BR,
George

On Wed, 20 May 2020 at 21:07, Karsten Horsmann  wrote:

> Hi Georg,
>
> setid is not an autoincrement.
>
> See the DB structure information (should be to your version)
> https://kamailio.org/docs/db-tables/kamailio-db-5.1.x.html#idm1963
>
> I group my targets with the setid. That's maybe the name "sets of id's"
>
> So all with the same id would be taken if the are active and how you call
> them from your kamailio.cfg.
>
> The other question is an implementation one. I don't understand the
> problem completely.
>
> Cheers
> Karsten
>
>
> George Diamantopoulos  schrieb am Mi., 20. Mai
> 2020, 19:42:
>
>> Hello all,
>>
>> I need to have two separate kamailio instances' dispatcher modules make
>> the same decisions when using algorithm 7 (hash over pvar). What do I need
>> to do to ensure this?
>>
>> Note that for design reasons, the two instances cannot share a dispatcher
>> table from db. If I ensure the "setid" group used for algo 7 in the
>> respective cases contain the same group of hosts, is it enough? Do other
>> things matter, such as the ordering of the group members in the table (i.e.
>> different AUTO INCREMENT ids?). Does the setid need to be the same number?
>> Do I need to ensure the 'destination' values are identical (i.e. not using
>> IPs for dispatcher table A and hostnames for dispatcher table B)?
>>
>> If someone knows what the criteria is for matching a hashed pvar to a
>> member of a dispatcher setid and how this can be made deterministic, I
>> would be grateful. Thanks!
>>
>> BR,
>> George
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] How to ensure separate kamailio instances dispatchers make the same decision?

[George Diamantopoulos]

Hello all,

I need to have two separate kamailio instances' dispatcher modules make the
same decisions when using algorithm 7 (hash over pvar). What do I need to
do to ensure this?

Note that for design reasons, the two instances cannot share a dispatcher
table from db. If I ensure the "setid" group used for algo 7 in the
respective cases contain the same group of hosts, is it enough? Do other
things matter, such as the ordering of the group members in the table (i.e.
different AUTO INCREMENT ids?). Does the setid need to be the same number?
Do I need to ensure the 'destination' values are identical (i.e. not using
IPs for dispatcher table A and hostnames for dispatcher table B)?

If someone knows what the criteria is for matching a hashed pvar to a
member of a dispatcher setid and how this can be made deterministic, I
would be grateful. Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio not using system resolver for hostname resolution (DMQ)?

[George Diamantopoulos]

Hello all,

Thank you for your enlightening answers. I ended up creating DNS entries
anyway, so it's all good now. use_dns_cache=no sounded a little scary :-).

BR.
George

On Tue, 19 May 2020 at 19:44, Daniel-Constantin Mierla 
wrote:

> A quick follow up as I found quite interesting that nowadays *BSDs allow
> specifying order of lookup in resolv.conf to include the hosts file, but
> that doesn't seem to be in Linux:
>
>   * https://man.openbsd.org/resolv.conf.5#lookup
>
> Cheers,
> Daniel
>
>
> On 19.05.20 17:48, Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > worth to clarify that Kamailio doesn't implement a dns resolver from
> > scratch, it still uses the functions from libc. It only does caching and
> > try to use cashing records first.
> >
> > By default, the following dns functions are used internally when the
> > cache doesn't have the record already -- they are set in the dns_func
> > structure:
> >
> > struct dns_func_t dns_func = {
> > res_init,
> > res_search,
> > gethostbyname,
> > #ifdef HAVE_GETHOSTBYNAME2
> > gethostbyname2
> > #else
> > NULL
> > #endif
> > };
> >
> > So practically by leveraging res_init()/res_search() is relying on
> > /etc/resolv.conf to do DNS queries, which is not using the /etc/hosts
> > (iirc). For more see:
> >
> >   * https://linux.die.net/man/3/res_search
> >
> > Cheers,
> > Daniel
> >
> > On 19.05.20 17:23, Alex Balashov wrote:
> >> You are correct that Kamailio does not use the libc resolver /
> >> libresolv, but rather its own resolver, which ignores /etc/hosts.
> >>
> >> -- Alex
> >>
> >> On 5/19/20 10:42 AM, George Diamantopoulos wrote:
> >>> Hello all,
> >>>
> >>> I've come across this today when trying to setup DMQ replication:
> >>>
> >>> root@sbcpub0-stage-lhe0-cn1:/root# systemctl restart kamailio
> >>> root@sbcpub0-stage-lhe0-cn1:/root# kamcmd dmq.list_nodes
> >>> {
> >>>  host: 172.30.154.189
> >>>  port: 5090
> >>>  resolved_ip: 172.30.154.189
> >>>  status: active
> >>>  last_notification: 0
> >>>  local: 1
> >>> }
> >>> root@sbcpub0-stage-lhe0-cn1:/root# getent hosts
> >>> dmq-ng.services.domain.com <http://dmq-ng.services.domain.com>
> >>> 172.30.154.189 dmq-ng.services.domain.com
> >>> <http://dmq-ng.services.domain.com>
> >>> 172.17.130.13 dmq-ng.services.domain.com
> >>> <http://dmq-ng.services.domain.com>
> >>>
> >>> root@sbcpub0-stage-lhe0-cn1:/root# grep dmq-ng /etc/kamailio/*
> >>> /etc/kamailio/kamailio-module-params.cfg:modparam("dmq",
> >>> "notification_address", "sip:dmq-ng.services.domain.com:5090
> >>> <http://dmq-ng.services.domain.com:5090>")
> >>>
> >>> In another case, where the resolving IPs for the DMQ service hostname
> >>> were listed as A records in DNS, this worked as expected.
> >>> In this case, the second host of the DMQ group is not listed in
> >>> dmq.list_nodes, despite its being set in /etc/hosts, as shown by the
> >>> getent command.
> >>>
> >>> Doesn't kamailio use nss for hostname resolution? Am I missing
> >>> something else? Thanks!
> >>>
> >>> BR,
> >>> George
> >>>
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>
> >> --
> >> Alex Balashov | Principal | Evariste Systems LLC
> >>
> >> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> >> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> >>
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > --
> > Daniel-Constantin Mierla -- www.asipto.com
> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
> > Funding: https://www.paypal.me/dcmierla
> >
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio not using system resolver for hostname resolution (DMQ)?

[George Diamantopoulos]

Hello all,

I've come across this today when trying to setup DMQ replication:

root@sbcpub0-stage-lhe0-cn1:/root# systemctl restart kamailio
root@sbcpub0-stage-lhe0-cn1:/root# kamcmd dmq.list_nodes
{
host: 172.30.154.189
port: 5090
resolved_ip: 172.30.154.189
status: active
last_notification: 0
local: 1
}
root@sbcpub0-stage-lhe0-cn1:/root# getent hosts dmq-ng.services.domain.com
172.30.154.189  dmq-ng.services.domain.com
172.17.130.13   dmq-ng.services.domain.com

root@sbcpub0-stage-lhe0-cn1:/root# grep dmq-ng /etc/kamailio/*
/etc/kamailio/kamailio-module-params.cfg:modparam("dmq",
"notification_address", "sip:dmq-ng.services.domain.com:5090")

In another case, where the resolving IPs for the DMQ service hostname were
listed as A records in DNS, this worked as expected.
In this case, the second host of the DMQ group is not listed in
dmq.list_nodes, despite its being set in /etc/hosts, as shown by the getent
command.

Doesn't kamailio use nss for hostname resolution? Am I missing something
else? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Generating provisional responses from kamailio instance

[George Diamantopoulos]

Hello all,

I would like to use rtpengine's media playback capabilities in an early
media scenario. The use case is as follows:

* Kamailio receives an incoming INVITE
* During INVITE processing, kamailio config script determines that an early
media message should be played back and then the call should fail with 4xx
* To that effect, Kamailio sends out a locally-generated 183 Progress and
instructs rtpengine to playback an audio file
* After the audio file has finished playing, kamailio responds with 4xx to
the INVITE

Is this possible at all? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to make a distinction between sip and tel uri

[George Diamantopoulos]

How about something like this:

  $vz(i) = 0;
  pv_unset("$vn(save_ai)")
  while ($vz(i) < $hdrc(P-Asserted-Identity)) {

  $vn(temp_holder) = $(hdr(P-Asserted-Identity)[$vz(i)]);

  if ( $(vn(temp_holder){nameaddr.uri}{uri.scheme}) =~ "^sip" ) {

$vn(save_ai) = $vn(temp_holder);

break;
  }
  }

  if ( $vn(save_ai) != $null ) {
remove_hf("P-Asserted-Identity");
append_hf("P-Asserted-Identity: $vn(save_ai)\r\n");
  }

might need some tuning, and you need the textops module.


On Wed, 29 Jan 2020 at 14:19, Duarte Rocha  wrote:

> Greetings,
>
> I have a client that sends me two P-Asserted-Identity headers, one with
> SIP URI and one with tel URI.
>
> The pseudo variable $ai returns the topmost P-Asserted-Identity header and
> I only need the one with the SIP URI.
>
> How should i proceed ? Is there a way to delete the one with tel URI? the
> header removal functions i find only work with header name.
>
> I could also work with something different than $ai for this scenario.
>
> Best Regards,
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Implicit branch creation and private variables questions - (Second Post)

[George Diamantopoulos]

To anyone reading this in the future: Point 2 in my original post is
completely misleading:

> If there are two destinations in the destination group for first_provider,
> and the first one fails, then the second destination will be tried out in
> tm:branch-failure:DISPATCH_FIRST_PROV_FAILOVER. Now the Via branch
> parameter for this INVITE is different than the original (.1 instead of
> .0), which one can verify by capturing the traffic on-net. However, in the
> logs, the respective branch route is only run once, and there's no
> reference to the ".1" Via, even with cfg script debugging enabled. I'm
> assuming this means that kamailio's definition of "branch" in the context
> of the configuration file is different to the notion of branch as a
> transaction identifier in SIP signalling in general? In simpler language,
> distinct branch identifiers in Via headers between two requests does not
> mean that these two requests were treated as separate branches in kamailio
> config: true or false?
>

There is indeed lines in the logs indicating that a new branch was created
as a result of actions taken in
tm:branch-failure:DISPATCH_FIRST_PROV_FAILOVER. The reason I missed it is
that I grepped the logs for Call-Id, which filtered those lines out.

On Wed, 22 Jan 2020 at 16:18, George Diamantopoulos 
wrote:

> Hello Daniel,
>
> Thanks for the input. That clears it up.
>
> @Ben Merrills: Glad to hear my rants are useful to other people as well
> :-). Branches are indeed among the more complicated concepts in kamailio
> scripting. I've always found resources that explain how things work much
> more useful than "how-to/examples" approaches to documentation when it
> comes to producing real-world configurations (Daniel and Ramona's kamailio
> ebook is a good starting point if you're struggling with grasping the
> larger picture). Maybe in part because I can't settle with something just
> working the way a set of requirements expect it to unless I also understand
> the why.
>
> BR,
> George
>
> On Wed, 22 Jan 2020 at 10:35, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> a new branch is created every time a request is sent out to a new
>> destination or resent to same destination after additional processing in a
>> failure route. append_branch() should not be needed, unless you want to
>> create more branches for parallel forking. Updating $ru or $du and doing
>> t_relay() in failure route should be all what is needed to send to a new
>> branch.
>>
>> To have branch route execution, be sure you set it before t_relay(), also
>> in failure route, even if you set it previously in request_route for first
>> branch -- in other words, t_on_branch() must be used for each step of
>> serial forking.
>>
>> The branch route block is executed inside t_relay(), so it is in the same
>> process that sends out the request, but in case of failure routing, further
>> branches are not created in the same process as the first branch. The best
>> is to use $xavp/$avp if you are not sure where and when those branch
>> processing happen.
>>
>> Cheers,
>> Daniel
>> On 21.01.20 23:22, George Diamantopoulos wrote:
>>
>> Hello all,
>>
>> Some keyboard shortcut resulted in gmail previously sending the message
>> out before I had finished writing it, sorry about that. This is the
>> complete message.
>>
>> I'm trying to accomplish the following scenario, and some questions have
>> arisen during testing: I'd like to be able to fork serially to a number of
>> downstream destinations in case of failure, but also try several hosts
>> which are available per destination network (via dispatcher module) before
>> failing over to the next one (e.g. try two gateways for provider A and if
>> both fail, then try two more gateways for provider B etc). I also need to
>> perform some network-specific handling per destination group (=provider),
>> which I thought I'd perform in respective branch routes. To that end, I'm
>> using something similar to the config pasted toward the end of the message.
>>
>> Here's some points that have troubled me, if anyone can provide some
>> insight:
>>
>>1. After exhausting dispatcher group entries for first_provider, the
>>request is indeed forwarded to last_provider with this configuration. I've
>>noticed a new branch is created. I'm assuming this happens because there's
>>some RURI manipulation taking place in branch_route? I recall reading
>>somewhere that even doing $ru = $ru will result in a new branch being
>>created. Is my assumption correct here, or is the new br

Re: [SR-Users] Parallel forking and rtpengine handling

[George Diamantopoulos]

On a side note, I think I might have found a bug for rtpengine_manage():
I'm under the impression that if called from within a branch_failure_route,
it will do an offer instead of a delete. Do you confirm and is this
intentional?

On Thu, 23 Jan 2020 at 11:06, Sebastian Damm  wrote:

> Hi,
>
> On Wed, Jan 22, 2020 at 8:29 PM Daniel-Constantin Mierla
>  wrote:
> > A remark for kamailio transaction states point of view: in failure route
> the entire transaction is in failed state, so there is not active branch,
> so at that point it should delete all (previous) rtpengine
> sessions/branches.
>
> This is what I had in mind. I don't think I end up in failure route if
> one branch is answered. My Question was, how to handle the canceled
> branch.
>
> > As I got it, the use of via-branch flag for deleting a session makes
> sense in event route for branch-failure, when other branches can still be
> active or one was answered.
>
> Do branches that get cancelled due to another branch answering the
> call go through the branch failure route?
>
> > Also in the case of parallel forking, if via-branch is not give to
> rtpengine offer command, does the 2nd (and the next) rtpengine offer
> command overwrite the previous one, so the rtpengine keeps only the data
> from the last one?
>
> We stumbled upon this problem only because we used rtpengine without
> the branch parameter. And what we saw was that the second
> rtpengine_offer overwrote the first one, making the first branch
> impossible to be answered in certain scenarios.
>
> Regards and thanks for all the answers so far.
> Sebastian
>
> --
> Sebastian Damm
> Voice Engineer
> __
> sipgate GmbH
> Gladbacher Straße 74 | 40219 Düsseldorf
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Parallel forking and rtpengine handling

[George Diamantopoulos]

On Wed, 22 Jan 2020 at 18:28, Richard Fuchs  wrote:

> On 22/01/2020 11.06, Sebastian Damm wrote:
> > Hi,
> >
> > our scenario is the following: We have two clients registered to our
> > Kamailio server, one with a TLS capable phone, one via websocket. Now,
> > when a call comes in, the call is forked and is sent out to both
> > clients. rtpengine handling is done in the branch route, so there are
> > two offers, and we use the "via-branch" parameter.
> >
> > Now, when one branch answers the call, what happens to the other
> > branch? I there a way to delete the other branch? How and in which
> > route? Or does Kamailio do this automatically?
>
> You do it the same way as you handle an answer: You issue a delete with
> the via-branch option.
>
Doesn't this happen automatically when one uses rtpengine_manage() in the
failure_route?

>
> Cheers
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Implicit branch creation and private variables questions - (Second Post)

[George Diamantopoulos]

Hello Daniel,

Thanks for the input. That clears it up.

@Ben Merrills: Glad to hear my rants are useful to other people as well
:-). Branches are indeed among the more complicated concepts in kamailio
scripting. I've always found resources that explain how things work much
more useful than "how-to/examples" approaches to documentation when it
comes to producing real-world configurations (Daniel and Ramona's kamailio
ebook is a good starting point if you're struggling with grasping the
larger picture). Maybe in part because I can't settle with something just
working the way a set of requirements expect it to unless I also understand
the why.

BR,
George

On Wed, 22 Jan 2020 at 10:35, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> a new branch is created every time a request is sent out to a new
> destination or resent to same destination after additional processing in a
> failure route. append_branch() should not be needed, unless you want to
> create more branches for parallel forking. Updating $ru or $du and doing
> t_relay() in failure route should be all what is needed to send to a new
> branch.
>
> To have branch route execution, be sure you set it before t_relay(), also
> in failure route, even if you set it previously in request_route for first
> branch -- in other words, t_on_branch() must be used for each step of
> serial forking.
>
> The branch route block is executed inside t_relay(), so it is in the same
> process that sends out the request, but in case of failure routing, further
> branches are not created in the same process as the first branch. The best
> is to use $xavp/$avp if you are not sure where and when those branch
> processing happen.
>
> Cheers,
> Daniel
> On 21.01.20 23:22, George Diamantopoulos wrote:
>
> Hello all,
>
> Some keyboard shortcut resulted in gmail previously sending the message
> out before I had finished writing it, sorry about that. This is the
> complete message.
>
> I'm trying to accomplish the following scenario, and some questions have
> arisen during testing: I'd like to be able to fork serially to a number of
> downstream destinations in case of failure, but also try several hosts
> which are available per destination network (via dispatcher module) before
> failing over to the next one (e.g. try two gateways for provider A and if
> both fail, then try two more gateways for provider B etc). I also need to
> perform some network-specific handling per destination group (=provider),
> which I thought I'd perform in respective branch routes. To that end, I'm
> using something similar to the config pasted toward the end of the message.
>
> Here's some points that have troubled me, if anyone can provide some
> insight:
>
>1. After exhausting dispatcher group entries for first_provider, the
>request is indeed forwarded to last_provider with this configuration. I've
>noticed a new branch is created. I'm assuming this happens because there's
>some RURI manipulation taking place in branch_route? I recall reading
>somewhere that even doing $ru = $ru will result in a new branch being
>created. Is my assumption correct here, or is the new branch created for
>some other reason? I mean if I did t_on_branch in a failure route following
>a t_relay which failed, but without manipulating the RURI in the new
>branch_route, would that still create an implicit new branch or would one
>have to use append_branch() or similar in this case?
>   - I'm asking because several implicit or explicit branch creation
>   mechanisms are documented in various places (e.g. usrloc, lcr, alias_db,
>   corex) but it's there's no comprehensive list for reference.
>   2. If there are two destinations in the destination group for
>first_provider, and the first one fails, then the second destination will
>be tried out in tm:branch-failure:DISPATCH_FIRST_PROV_FAILOVER. Now the Via
>branch parameter for this INVITE is different than the original (.1 instead
>of .0), which one can verify by capturing the traffic on-net. However, in
>the logs, the respective branch route is only run once, and there's no
>reference to the ".1" Via, even with cfg script debugging enabled. I'm
>assuming this means that kamailio's definition of "branch" in the context
>of the configuration file is different to the notion of branch as a
>transaction identifier in SIP signalling in general? In simpler language,
>distinct branch identifiers in Via headers between two requests does not
>mean that these two requests were treated as separate branches in kamailio
>config: true or false?
>3. This is causing the most problems for me right now: the $vn PVs
>seem to be ava

[SR-Users] Implicit branch creation and private variables questions

[George Diamantopoulos]

Hello all,

I'm trying to accomplish the following scenario, and some questions have
been raised during testing: I'd like to be able to fork serially to a
number of downstream destinations in case of failure, but also try several
hosts which are available per destination network before failing over to
the next one. To that end, I'm using something similar to the following:

request_route {
...
$vn(some_var) = "some_value";
$vn(some_other_var) = "some_other_value";
...
$avp(provider_order) = "last_provider";
$avp(provider_order) = "first_provider";
...
t_set_fr(12, 2000);
route(PROVIDER_SELECTION);
...
}

route[PROVIDER_SELECTION] {
if ( is_avp_set("$avp(provider_order)") ) {
t_on_failure("PROVIDER_SERIAL");
if ( $avp(provider_priority) == "first_provider" )
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] siputils: how does sip_p_charging_vector generate the header

[George Diamantopoulos]

Hello again,

Following some tests, it only seems to generate two params:
P-Charging-Vector: icid-value=495653AC1E9A01FD15DE;
icid-generated-at=172.30.154.1

I'm guessing one can manipulate the header afterwards, but not before
running msg_apply_changes() (I'm assuming, I haven't actually tested this),
which is kind of unfortunate. Also the function's usefulness remains
limited if there's no way to provide a custom string for the
icid-generated-at parameter's value...

BR,
George

On Fri, 29 Nov 2019 at 17:34, Henning Westerholt  wrote:

> Hello,
>
>
>
> haven’t tried it myself, but have you tried this function already:
>
>
> https://kamailio.org/docs/modules/5.1.x/modules/siputils.html#siputils.f.sip_p_charging_vector
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Thursday, November 28, 2019 10:09 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] siputils: how does sip_p_charging_vector generate
> the header
>
>
>
> Hello,
>
>
>
> I've been looking at the sip_p_charging_vector() function of siputils.
> From the documentation it is not evident how the PCV header is generated.
> Are the exported $pcv pseudovariables writable, so that the function canl
> use those when generating the header? Thanks!
>
>
>
> BR,
>
> George
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] siputils: how does sip_p_charging_vector generate the header

[George Diamantopoulos]

Hello,

I've been looking at the sip_p_charging_vector() function of siputils. From
the documentation it is not evident how the PCV header is generated. Are
the exported $pcv pseudovariables writable, so that the function canl use
those when generating the header? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[George Diamantopoulos]

Thank you both for your input. I guess I'll continue calling dlg_manage()
for in-dialog requests for now until I gather more feedback, since we do
cater for a large set of endpoints and several have at times exhibited
various offending behaviours.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[George Diamantopoulos]

Hello all,

I've been reading through the dialog module docs again, and there seems to
be a discrepancy in what's suggested in the docs. In the intro, it is
stated that 'To create the dialog associated with an initial INVITE
request, execute the function “dlg_manage()"'. Later on, in section "7.10"
the following example code is provided:
request_route {
...
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = "DLGTIMEOUT";
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
...
}
In this example code, dlg_manage seems to be called for all requests, as it
is not dependent on the conditional that only requests with no to-tag are
to be handled.

Previously, Daniel had suggested to me in person that one also run
dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to
mitigate some buggy corner cases. Is this still the case?

What do you guys and gals do in production? Have you had to revise how you
use dlg_manage in terms of calling it for initial INVITEs only vs all
requests? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using static entries with usrloc

[George Diamantopoulos]

Thank you all for your input. I'll most likely use the RPC command to add
entries expiring at the end of linux time and see how it goes. Cheers!

On Fri, 20 Sep 2019 at 16:37, George Diamantopoulos 
wrote:

> Hello,
>
> Normally I wouldn't be asking this but I was surprised to find no
> reference to anyone doing this online. I need to have a few AoRs with
> static entries in kami's location table, which will always be reachable at
> their contacts without ever having to register with Kamailio.
>
> Am I right in thinking that merely INSERTing respective rows in kamailio's
> location DB backend will do the trick? Is there anything I need to worry
> about, like contacts being periodically purged? If yes, how do I prevent
> that from happening? And will kamailio always query the DB when performing
> location lookup or do I need to restart upon inserting new records (to
> purge caches, for example)?
>
> Lastly, I'm not sure how to treat some fields present in usrloc tables
> like ruid, expires (can I set this to NULL?), callid and cseq (which is
> irrelevant since there's no REGISTER), flags, cflags and methods.
>
> Thanks,
> George
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Using static entries with usrloc

[George Diamantopoulos]

Hello,

Normally I wouldn't be asking this but I was surprised to find no reference
to anyone doing this online. I need to have a few AoRs with static entries
in kami's location table, which will always be reachable at their contacts
without ever having to register with Kamailio.

Am I right in thinking that merely INSERTing respective rows in kamailio's
location DB backend will do the trick? Is there anything I need to worry
about, like contacts being periodically purged? If yes, how do I prevent
that from happening? And will kamailio always query the DB when performing
location lookup or do I need to restart upon inserting new records (to
purge caches, for example)?

Lastly, I'm not sure how to treat some fields present in usrloc tables like
ruid, expires (can I set this to NULL?), callid and cseq (which is
irrelevant since there's no REGISTER), flags, cflags and methods.

Thanks,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to statelessly send a reply to custom destination?

[George Diamantopoulos]

Thank you for the reply Karsten!

I'm afraid the options_reply() function won't work for me. The reason is
that it seems to only handle OPTIONS where the RURI username is not set,
and in my case I need to be able to handle these cases.

Moreover, it is not evident from the siputils module documentation if it
will perform NAT traversal on the side of kamailio, which is my original
problem. I'm beginning to think I can't serve NATted endpoints' requests
statelessly and that I'd have to handle the reply statefully, am I right in
thinking that?

BR,
George

On Fri, 5 Jul 2019 at 09:37, Karsten Horsmann  wrote:

> Hi George,
>
> i use something like that (shameless stolen from other configuration files
> within request-route).
>
> Thats for answering options to my internal kamailio.
> But Alex Balashov wrote an nice blog poste about NAT/OPTION Pings
> with kamailio:
> http://www.evaristesys.com/blog/server-side-nat-traversal-with-kamailio-the-definitive-guide/
>
> ### only initial requests (no To tag)
> if (is_method("OPTIONS"))
> {
> if (uri=~"sip:.*[@]+.*")  {
> sl_send_reply("501", "Not Implemented");
> }
> else {
> options_reply();
>     exit;
> }
> }
>
> Cheers Karsten
>
> Am Do., 4. Juli 2019 um 10:29 Uhr schrieb George Diamantopoulos <
> georged...@gmail.com>:
>
>> Hello all,
>>
>> I've been trying to handle OPTIONS statelessly, but proper handling fails
>> for UACs behind NAT without ALG. I thought I'd overcome this by setting the
>> $du pseudovariable, but apparently I'm missing something. The following
>> does not work:
>>
>> if ($Rp == "6050") {
>> force_send_socket(udp:10.10.10.10:6050);
>> }
>> $du = "sip:" + $si + ":" + $sp;
>> sl_send_reply("200","OK");
>> exit;
>>
>> I'm now realising that I put this in request_route() so
>> force_send_socket() and $du have no use whatsoever, since the request is
>> not forwarded anywhere. Is this the reason?
>>
>> So the question is, how can I do the following things for a stateless
>> reply: a) choose a sending socket for the reply and b) change the
>> destination for the reply to something other than the URI in the first Via
>> header.
>>
>> Thanks!
>>
>> BR,
>> George
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Mit freundlichen Grüßen
> *Karsten Horsmann*
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] How to statelessly send a reply to custom destination?

[George Diamantopoulos]

Hello all,

I've been trying to handle OPTIONS statelessly, but proper handling fails
for UACs behind NAT without ALG. I thought I'd overcome this by setting the
$du pseudovariable, but apparently I'm missing something. The following
does not work:

if ($Rp == "6050") {
force_send_socket(udp:10.10.10.10:6050);
}
$du = "sip:" + $si + ":" + $sp;
sl_send_reply("200","OK");
exit;

I'm now realising that I put this in request_route() so force_send_socket()
and $du have no use whatsoever, since the request is not forwarded
anywhere. Is this the reason?

So the question is, how can I do the following things for a stateless
reply: a) choose a sending socket for the reply and b) change the
destination for the reply to something other than the URI in the first Via
header.

Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] Planning Fosdem 2019

[George Diamantopoulos]

So are we not gathering at the K building this year? Going directly to the
restaurant?

On Mon, 28 Jan 2019, 08:33 Daniel-Constantin Mierla  Forgot to mention the time: at 19:00, on Saturday, the 2nd of February.
>
> Cheers,
> Daniel
>
> On 28.01.19 08:29, Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > if you registered for the dinner at Fosdem 2019, note the venue details:
> >
> > Restaurant Le Pickwick
> > Ave Adolphe Buyl 77-79
> > 1050 Brussels (Ixelles)
> >
> > It is same location like last year, nearby Fosdem area.
> >
> > Thanks again to Torrey Searle (from Voxbone) for taking care of
> reservation.
> >
> > If you announced yourself till now, you have the seats reserved.
> >
> > Few more spots are available, if you write that you want to join, wait
> > for my confirmation to be sure we can accommodate you.
> >
> > Cheers,
> > Daniel
> >
> > On 16.01.19 11:02, Daniel-Constantin Mierla wrote:
> >> Hello,
> >>
> >> soon we will have to do the reservation, so here is a reminder for those
> >> that plan to join the dinner, but they haven't announced it, do it as
> >> soon as possible to count you in and be sure we have enough seats.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On 08.01.19 16:28, Daniel-Constantin Mierla wrote:
> >>> Hello,
> >>>
> >>> Fosdem 2019 is approaching, so I am writing to see if any of you plans
> >>> to go to the event. If there is interest, we can try to organize again
> a
> >>> dinner on Saturday evening, a tradition for our project at the past 10
> >>> editions or even more.
> >>>
> >>> Henning Westerholt will give a presentation about Kamailio in the RTC
> >>> Devroom, I will be around as well. I know few more developers that plan
> >>> to go to the event, so let's see who else from the community wants to
> >>> join us. As usual, at Fosdem will be developers from other VoIP
> >>> projects, like Asterisk, Janus, CGRates, Homer, Jitsi, ...
> >>>
> >>> At the past editions we typically had two "kamailio" events:
> >>>
> >>>   1)  an "ad-hoc" developers meeting in the cantina (or other available
> >>> room around) to discuss about short term plans for Kamailio -- time and
> >>> place being decided as we meet there between us (expected in the
> >>> afternoon of Saturday or during Sunday).
> >>>
> >>>   2) a dinner at a place nearby, with other VoIP folks joining us
> >>>
> >>> Reply if you plan to go to Fosdem and say if you want to join for a
> >>> dinner. Just be aware that you have to pay for your food and drinks at
> >>> the dinner, unless we are going to be surprised again by a generous
> >>> sponsor that covers partially or completely to dinner.
> >>>
> >>> If you need more details about Fosdem, the website is:
> >>>
> >>>   - https://fosdem.org
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
> Washington, DC, USA -- www.asipto.com
>
>
> ___
> Kamailio (SER) - Development Mailing List
> sr-...@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPengine: shouldn't SDP be incremented when SDP is updated in-dialog?

[George Diamantopoulos]

We've run into an issue again, where a provider won't accept re-INVITEs for
session refresh where the SDP version counter hasn't been incremented. Has
there been any work on this or should I open an issue at github to make
this issue more visible?

Thanks!
George

On Fri, 4 May 2018 at 17:51, Richard Fuchs  wrote:

> On 04/11/2018 09:28 AM, George Diamantopoulos wrote:
> > Hello all,
> >
> > I have the following issue (I think) with RTP engine. An INVITE comes
> > in, and rtpengine will rewrite the SDP accordingly, as configured in
> > kamailio.cfg. After some time a reINVITE is sent out in the opposite
> > direction, for session refresh purposes. As I use rtcp-mux-offer in
> > kamailio.cfg for this direction, RTPengine will inject the rtcp-mux
> > parameter, and this reINVITE is forwarded to the UAC that sent the
> > original INVITE.
> >
> > However, the SDP in the reINVITE is exactly the same as the SDP in the
> > 200 OK to the original INVITE, with the exception of the rtcp-mux
> > parameter. Since the SDP offered from the same end has changed,
> > shouldn't session version be incremented as well?
> >
> > Does this sound like something that should be reported as a bug to
> > rtpengine? Or am I missing something here?
>
> Technically of course you're correct in that the version counter should
> be incremented if the SDP changed. Currently rtpengine always leaves the
> o= line unchanged, so there can be a discrepancy here in certain cases.
> This should probably be fixed, but this is also the first time I've
> heard of this actually causing an issue.
>
> Cheers
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Is it possible to change a positive (2xx) response to a negative one (4xx) during kamailio processing of a reply (g711 fallback drama)?

[George Diamantopoulos]

Theoretically speaking though, and notwithstanding any FDA restrictions on
this, would it be possible to collect the cow's milk, process all lactose
out with event_route[network:msg] and then distribute to undiagnosed
intolerant consumers?

I guess no one will encourage me to go through with that, but should I
decide nonetheless to give it a go it would save me some trouble if I knew
it can't be done beforehand...

On 21 May 2018 at 22:29, Alex Balashov <abalas...@evaristesys.com> wrote:

> On Mon, May 21, 2018 at 10:28:06PM +0300, George Diamantopoulos wrote:
>
> > I know, but I'm that desperate.
>
> Sometimes you just have to solve the problem differently. Can't put the
> milk back into the cow.
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Is it possible to change a positive (2xx) response to a negative one (4xx) during kamailio processing of a reply (g711 fallback drama)?

[George Diamantopoulos]

I know, but I'm that desperate.

On 21 May 2018 at 22:17, Alex Balashov <abalas...@evaristesys.com> wrote:

> I think this is the wrong job for Kamailio.
>
> On Mon, May 21, 2018 at 10:16:20PM +0300, George Diamantopoulos wrote:
>
> > Hello all,
> >
> > I've been hitting a wall in getting T.38 fallback to G.711 to work in a
> > specific case, and I was wondering if I could use kamailio to the rescue,
> > since all my other endeavours have failed miserably.
> >
> > In short, this is this the scenario where I need to have this
> manipulation
> > happen:
> > - During an established dialog between a SIP endpoint and asterisk (with
> > kamailio in the middle acting as proxy), the latter (asterisk) sends a
> > re-INVITE with a single offer for m=image with T.38 in the SDP.
> > - The other (eccentric) endpoint (yes, it's a Cisco) replies with 200 OK,
> > but will reject the T.38 offer in the SDP body instead by including a
> port
> > number of '0'
> > - Instead of falling back to G.711 as configured, asterisk in that case
> > will do nothing, and the dialog will eventually end with a BYE (don't
> > remember which of the two endpoints will send that, but it doesn't matter
> > much)
> >
> > The thing here is that asterisk *WILL* fallback to G711 with a second
> > re-INVITE, if the other endpoint replies to the first T.38 re-INVITE
> with a
> > negative response (488) instead of a positive one (200) declining the
> media
> > in the SDP body. I've looked at using freeswitch for a fax gateway
> instead,
> > but apparently FS doesn't support fallback at all even in the 488 reply
> > case, much less in the inactive media stream in 200 OK corner case I'm
> > investigating.
> >
> > So, I thought I'd do that in kamailio and convert those 200 OKs to 488s
> > with change_reply_status() from the textopsx module. Of course, the
> > universe hates me, and this will fail spectacularly:
> >
> > > ERROR: textopsx [textopsx.c:301]: ki_change_reply_status(): the class
> of
> > provisional or positive final replies cannot be changed
> >
> > So you can't change a reply's "class" with change_reply_status(), only
> the
> > response code within that class can be manipulated.
> >
> > I guess my question is now whether there is any way to do this sort of
> > transformation with kamailio, perhaps with some other function or method?
> >
> > If anyone else has had to deal with this problem and come up with a
> > different solution I'd be glad to hear it, as neither my head nor the
> > surrounding walls can take any more mutual banging at this point. Thanks!
> >
> > BR,
> > George.
> >
> > P.S. I hate fax
>
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Is it possible to change a positive (2xx) response to a negative one (4xx) during kamailio processing of a reply (g711 fallback drama)?

[George Diamantopoulos]

Hello all,

I've been hitting a wall in getting T.38 fallback to G.711 to work in a
specific case, and I was wondering if I could use kamailio to the rescue,
since all my other endeavours have failed miserably.

In short, this is this the scenario where I need to have this manipulation
happen:
- During an established dialog between a SIP endpoint and asterisk (with
kamailio in the middle acting as proxy), the latter (asterisk) sends a
re-INVITE with a single offer for m=image with T.38 in the SDP.
- The other (eccentric) endpoint (yes, it's a Cisco) replies with 200 OK,
but will reject the T.38 offer in the SDP body instead by including a port
number of '0'
- Instead of falling back to G.711 as configured, asterisk in that case
will do nothing, and the dialog will eventually end with a BYE (don't
remember which of the two endpoints will send that, but it doesn't matter
much)

The thing here is that asterisk *WILL* fallback to G711 with a second
re-INVITE, if the other endpoint replies to the first T.38 re-INVITE with a
negative response (488) instead of a positive one (200) declining the media
in the SDP body. I've looked at using freeswitch for a fax gateway instead,
but apparently FS doesn't support fallback at all even in the 488 reply
case, much less in the inactive media stream in 200 OK corner case I'm
investigating.

So, I thought I'd do that in kamailio and convert those 200 OKs to 488s
with change_reply_status() from the textopsx module. Of course, the
universe hates me, and this will fail spectacularly:

> ERROR: textopsx [textopsx.c:301]: ki_change_reply_status(): the class of
provisional or positive final replies cannot be changed

So you can't change a reply's "class" with change_reply_status(), only the
response code within that class can be manipulated.

I guess my question is now whether there is any way to do this sort of
transformation with kamailio, perhaps with some other function or method?

If anyone else has had to deal with this problem and come up with a
different solution I'd be glad to hear it, as neither my head nor the
surrounding walls can take any more mutual banging at this point. Thanks!

BR,
George.

P.S. I hate fax
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPengine: shouldn't SDP be incremented when SDP is updated in-dialog?

[George Diamantopoulos]

Has anyone run into or is concerned by this? Thanks!

On 11 April 2018 at 16:28, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello all,
>
> I have the following issue (I think) with RTP engine. An INVITE comes in,
> and rtpengine will rewrite the SDP accordingly, as configured in
> kamailio.cfg. After some time a reINVITE is sent out in the opposite
> direction, for session refresh purposes. As I use rtcp-mux-offer in
> kamailio.cfg for this direction, RTPengine will inject the rtcp-mux
> parameter, and this reINVITE is forwarded to the UAC that sent the original
> INVITE.
>
> However, the SDP in the reINVITE is exactly the same as the SDP in the 200
> OK to the original INVITE, with the exception of the rtcp-mux parameter.
> Since the SDP offered from the same end has changed, shouldn't session
> version be incremented as well?
>
> Does this sound like something that should be reported as a bug to
> rtpengine? Or am I missing something here?
>
> Thanks!
>
> Best regards,
> George Diamantopoulos
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Determining next hop for any SIP message

[George Diamantopoulos]

Hello all,

Just one last attempt at clearing the following points, if someone feels
confident enough to answer:

* Does $nh(d) work when the Route header enforces the next-hop in an
in-dialog request?
* Is it safe to determine next hop for responses by looking at the first
Via header only, or are there exceptions to this?

Thanks!

BR,
George

On 13 April 2018 at 21:29, George Diamantopoulos <georged...@gmail.com>
wrote:

> I guess you're right...
>
> But if it is possible to do this with different means, I would prefer it...
>
> I think I only miss the following points:
>
> * Does $nh(d) work when the Route header enforces the next-hop in an
> in-dialog request?
> * Is it safe to determine next hop for responses by looking at the first
> Via header only, or are there exceptions to this?
>
> BR,
> George
>
> On 13 April 2018 at 21:20, Alex Balashov <abalas...@evaristesys.com>
> wrote:
>
>> That's probably true of any Kamailio functionality. :-) But point taken.
>>
>> On April 13, 2018 2:09:10 PM EDT, George Diamantopoulos <
>> georged...@gmail.com> wrote:
>> >Well, the "SIP routing with Kamailio" book by Daniel and Elena states:
>> >
>> >"Defining the onsend_route should be done only if really needed,
>> >because it
>> >is executed for each request sent out, excluding the retransmissions."
>> >
>> >Also, it similarly won't work for responses, only for requests...
>> >
>> >On 13 April 2018 at 21:00, Alex Balashov <abalas...@evaristesys.com>
>> >wrote:
>> >
>> >> "A simpler way to do it, of course, would be to use the onsend_route,
>> >but
>> >> that would most likely introduce an unnecessary overhead for all
>> >routed
>> >> messages."
>> >>
>> >> What informs that assumption?
>> >>
>> >> I suppose there is a measurable nonzero performance penalty to
>> >anything,
>> >> but it should be negligible.
>> >>
>> >> -- Alex
>> >>
>> >> --
>> >> Sent via mobile, please forgive typos and brevity.
>> >>
>> >> ___
>> >> Kamailio (SER) - Users Mailing List
>> >> sr-users@lists.kamailio.org
>> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >>
>>
>>
>> -- Alex
>>
>> --
>> Sent via mobile, please forgive typos and brevity.
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

[George Diamantopoulos]

Hello all,

Do you expect the DMQ vs database advantages to still hold true even when
considering REDIS as a database (new backend in devel should make this
possible)? Or are these points mainly relevant when it comes to
traditional, persistent storage databases like mySQL? Thanks!

BR,
George

On 27 April 2018 at 21:23, Charles Chance 
wrote:

> Hello Joel,
>
> +1 to everything Alex has said. Using DMQ simplifies/flattens the stack
> and allows for a truly decoupled cluster with fewer points of failure.
>
> In production we use DMQ for htable, usrloc, dialog and presence, where
> previously we were using MySQL with Percona - now, performance is vastly
> improved and the admin overhead is greatly reduced.
>
> Disclaimer: I am possibly very slightly biased!
>
> Cheers,
>
> Charles
>
>
> On Fri, 27 Apr 2018 at 16:45, Alex Balashov 
> wrote:
>
>> Hello Joel,
>>
>> Our experience with using DMQ for dialog and usrloc replication has been
>> very positive, and we recommend it wholeheartedly over the crusty
>> database sync-based methods.
>>
>> The primary appeal comes from the fact that the replication is done at a
>> higher level, so there is no need to contend with issues surrounding the
>> degree of two-way coupling that DB-backed modules have. For instance,
>> the dialog module has both "runtime" and "persistent" components to its
>> backing, so while the dialog module can store dialog info in a DB table,
>> it can't store profile info. Replicating dialogs via DMQ allows one to
>> share profile state.
>>
>> And in general, it's a lot more efficient. If you have 3 or 4
>> registrars, you have a reasonable degree of persistence if you use in
>> memory-only storage for usrloc with DMQ replication. That takes an
>> enormous workload off the database.
>>
>> Databases are for storage; they aren't great for highly ephemeral,
>> short-lived, real-time data, though they're often (mis)used for that
>> purpose:
>>
>> https://en.wikipedia.org/wiki/Database-as-IPC
>>
>> DMQ solves a much-needed gap here in Kamailio, and I hope it is extended
>> to provide transport for other components too.
>>
>> -- Alex
>>
>> On Fri, Apr 27, 2018 at 08:31:56AM -0700, Joel Serrano wrote:
>>
>> > Hi all,
>> >
>> > Just wanted to know what your opinions were on using DMQ modules over
>> > database for things like dialog replication, registrations, etc...
>> >
>> > Is DMQ the "new way to go"? I know that there lots of ways of doing
>> things
>> > with each having pros/cons... But I was wondering...
>> >
>> > What does the community think on this topic?
>> >
>> > Are you guys taking advantage of the DMQ modules or are you still
>> relying
>> > on database as much as possible? Maybe a combination of both?
>> >
>> > Cheers,
>> > Joel.
>>
>> > ___
>> > Kamailio (SER) - Users Mailing List
>> > sr-users@lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio config file String Concatenation

[George Diamantopoulos]

Hello,

I'm a a bit confused as to when string concatenation will work in kamailio
config file. So far I have identified the following cases:

Working:

As part of the right hand side of an assignment:
$var(x) = "string1" + "string2";

String argument of some functions:
xlog("L_ERR", "string1" + "string2" + DEFINED_STRING + '\n');

Conditional Statements:
if ( ru =~ "$" + "sip:" + $var(user) ) {

Not Working:

In string transformations (the fact that quotes is not part of the argument
should give a hint though:
$var(x) = $(var(y){s.replace,match,"repl1" + "repl2"});

String argument of some other functions:
append_hf_value("P-Asserted-Identity", "<" + "$var(new_pai)" + ">");
lookup("location", "sip:$var(username)@" + SIP_REALM_DEFINITION));

In module parameter definitions:
modparam("nathelper", "sipping_from", "sip:keepalive@" +
SIP_REALM_DEFINITION)

So far, I have found this to be fairly consistent, except for use within
functions. For example, string concatenation works for the second argument
of xlog, but not for the string arguments of append_hf_value() or lookup().

Is there anyway to know this for each function beforehand, or is my only
choice to go through trial and error here? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] phonenum module erratic behaviour with 5.1.2

[George Diamantopoulos]

Hello Daniel!

Thanks for the lightning fast fix :-). I have tested with both
libphonenumber7 and libphonenumber8 and it works with current master now!

Do you think it would be possible add more attributes in the future? Like
region and operator? I know the quality of that info is not great but it
might be nice to have for some territories. Thanks!

BR,
George

On 21 March 2018 at 16:15, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:

> Hello,
>
> on the flight to Singapore for Fossasia, I got a bit of time to look at it
> and the main issue was the documentation, it was no sync'ed with the code
> -- the readme listed different attribute names.
>
> In addition, I also found a bug on matching the pv name. Can someone test
> with master branch and if all ok, I will backport.
>
> For pv attribute names, see wiki at:
>
>   * https://www.kamailio.org/wiki/cookbooks/devel/
> pseudovariables#phn_rid_key_-_phonenum_variables
>
> Cheers,
> Daniel
>
> On 21.03.18 13:09, Anthony Joseph Messina wrote:
>
> George, I do see the same problem, though I haven't had time to investigate
> yet.  -A
>
> On Monday, March 19, 2018 1:16:17 PM CDT George Diamantopoulos wrote:
>
> Hello all,
>
> It seems that the phonenum module in at least 5.1.2 (haven't tried previous
> versions) is behaving somewhat erratically. More specifically, if there are
> any references to any phn PVs with the key other than "number":
>
> if ( phonenum_match("1-484-555-", "src") ) {
> xlog("number norm: $phn(src=>number)\n");
> xlog("number country: $phn(src=>country)\n");
> dbg_pv_dump(30, "L_ERR");
> }
>
> kamailio will not start:
>
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: 
> [core/pvapi.c:494]: pv_spec_lookup(): PV <$phn(src=>country)> is not in
> cache
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: phonenum
> [phonenum_pv.c:160]: pv_parse_phonenum_name(): phonenum [src] - key
> [country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: phonenum
> [phonenum_pv.c:205]: pv_parse_phonenum_name(): error at PV phonenum name:
> src=>country
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
> [core/pvapi.c:951]: pv_parse_spec2(): pvar "phn" has an invalid name param
> [src=>country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
> [core/pvapi.c:1106]: pv_parse_spec2(): wrong char [)/41] in
> [$phn(src=>country)] at [17 (5)]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: xlog
> [xlog.c:513]: xdbg_fixup_helper(): wrong format[number country:
> $phn(src=>country)
>
> If I comment the offending line, all is well, but when dumping PVs with
> dbg_pv_dump(30, "L_ERR");, only $phn(src=>number) is listed, not the other
> keys (country, operator, region according to the docs)
>
> However, what is more disturbing is that phn(src=>number) always contains
> the string provided to phonenum_match() function, even if invalid
> characters are included, with no normalization. For example:
>
> phonenum_match("14~8%^88", "src")
>
> will result in dbg_pv_dump reporting:
>
> "$phn(src=>number)": "14~8%^88"
>
> Please note that I'm using sipwise's debian repository for stretch for
> kamailio, and debian's stable stretch repository for libphonenumnber
> (currently at 7.1.0-5+b1). I have also tried building current
> libphonenumber myself (version v8.9.2), but the result is the same.
>
> Is this a bug? Or am I missing something? Thanks!
>
> BR,
> George
>
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] phonenum module erratic behaviour with 5.1.2

[George Diamantopoulos]

Any phonenum users out there? Could really use any kind of input on this...
Thanks!

On 19 March 2018 at 20:16, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello all,
>
> It seems that the phonenum module in at least 5.1.2 (haven't tried
> previous versions) is behaving somewhat erratically. More specifically, if
> there are any references to any phn PVs with the key other than "number":
>
> if ( phonenum_match("1-484-555-", "src") ) {
> xlog("number norm: $phn(src=>number)\n");
> xlog("number country: $phn(src=>country)\n");
> dbg_pv_dump(30, "L_ERR");
> }
>
> kamailio will not start:
>
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: 
> [core/pvapi.c:494]: pv_spec_lookup(): PV <$phn(src=>country)> is not in
> cache
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: phonenum
> [phonenum_pv.c:160]: pv_parse_phonenum_name(): phonenum [src] - key
> [country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: phonenum
> [phonenum_pv.c:205]: pv_parse_phonenum_name(): error at PV phonenum name:
> src=>country
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
> [core/pvapi.c:951]: pv_parse_spec2(): pvar "phn" has an invalid name param
> [src=>country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
> [core/pvapi.c:1106]: pv_parse_spec2(): wrong char [)/41] in
> [$phn(src=>country)] at [17 (5)]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: xlog
> [xlog.c:513]: xdbg_fixup_helper(): wrong format[number country:
> $phn(src=>country)
>
> If I comment the offending line, all is well, but when dumping PVs with
> dbg_pv_dump(30, "L_ERR");, only $phn(src=>number) is listed, not the other
> keys (country, operator, region according to the docs)
>
> However, what is more disturbing is that phn(src=>number) always contains
> the string provided to phonenum_match() function, even if invalid
> characters are included, with no normalization. For example:
>
> phonenum_match("14~8%^88", "src")
>
> will result in dbg_pv_dump reporting:
>
> "$phn(src=>number)": "14~8%^88"
>
> Please note that I'm using sipwise's debian repository for stretch for
> kamailio, and debian's stable stretch repository for libphonenumnber
> (currently at 7.1.0-5+b1). I have also tried building current
> libphonenumber myself (version v8.9.2), but the result is the same.
>
> Is this a bug? Or am I missing something? Thanks!
>
> BR,
> George
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] execute only on INITIAL INVITE

[George Diamantopoulos]

I ain't sure about UPDATEs though. Can they be sent without a to-tag as
well? I believe they can, as one can theoretically immediately follow an
initial INVITE... If that's the case, perhaps you shouldn't check for those
as well:

if ( !has_totag() && !is_method("UPDATE") )

Perhaps a list member with more insight into the UPDATE method could shed
some more light on this...

On 20 March 2018 at 20:16, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello David,
>
> First of all your checking for a to-tag is correct. In-dialog requests
> should have a to-tag, and therefore the block you pasted here won't execute
> at all for those.
>
> If you're worrying about provisional (1xx) replies sent from the UAS for
> the initial INVITE, then indeed some of them might also not have a to-tag
> set. However, if the code block you pasted is in the request_route() "main"
> route, then it won't be executed anyway. For responses to be specially
> processed via the configuration script, you either have to have a
> reply_route() set, or an onreply_route() set if you're doing stateful
> processing with the tm module.
>
> BR,
> George
>
> On 20 March 2018 at 20:03, David Villasmil <david.villasmil.w...@gmail.com
> > wrote:
>
>> Hello guys,
>>
>> I want to execute an sql only for INITIAL INVITEs, I'm trying like:
>>
>> #!ifdef WITH_DID_VALIDATE
>> if(!has_totag()) {
>> sql_query("acd", "select * from did_numbers where didNumber
>> = '$tU' and active = 'Y'", "ra");
>> xlog("L_ERR", "[REQUEST_ROUTE] number of rows in table
>> domain: $dbr(ra=>rows)\n");
>> if( $dbr(ra=>rows)==0 ) {
>> xlog("L_ERR", "[REQUEST_ROUTE] DID Number validation
>> returned [$dbr(ra=>rows)], not responding to this request\n");
>> exit;
>> }
>> sql_result_free("ra");
>> }
>> #!endif
>>
>> But, say I remove the DID from the allowed list while a call is going on.
>> Then responses to the allowed INVITE would not be processed.
>>
>> How would I limit that to ONLY the INITIAL INVITE? Should I use has_totag?
>>
>> Thanks!
>>
>> David
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337 <+34%20669%2044%2083%2037>
>> ᐧ
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] execute only on INITIAL INVITE

[George Diamantopoulos]

Hello David,

First of all your checking for a to-tag is correct. In-dialog requests
should have a to-tag, and therefore the block you pasted here won't execute
at all for those.

If you're worrying about provisional (1xx) replies sent from the UAS for
the initial INVITE, then indeed some of them might also not have a to-tag
set. However, if the code block you pasted is in the request_route() "main"
route, then it won't be executed anyway. For responses to be specially
processed via the configuration script, you either have to have a
reply_route() set, or an onreply_route() set if you're doing stateful
processing with the tm module.

BR,
George

On 20 March 2018 at 20:03, David Villasmil 
wrote:

> Hello guys,
>
> I want to execute an sql only for INITIAL INVITEs, I'm trying like:
>
> #!ifdef WITH_DID_VALIDATE
> if(!has_totag()) {
> sql_query("acd", "select * from did_numbers where didNumber =
> '$tU' and active = 'Y'", "ra");
> xlog("L_ERR", "[REQUEST_ROUTE] number of rows in table
> domain: $dbr(ra=>rows)\n");
> if( $dbr(ra=>rows)==0 ) {
> xlog("L_ERR", "[REQUEST_ROUTE] DID Number validation
> returned [$dbr(ra=>rows)], not responding to this request\n");
> exit;
> }
> sql_result_free("ra");
> }
> #!endif
>
> But, say I remove the DID from the allowed list while a call is going on.
> Then responses to the allowed INVITE would not be processed.
>
> How would I limit that to ONLY the INITIAL INVITE? Should I use has_totag?
>
> Thanks!
>
> David
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337 <+34%20669%2044%2083%2037>
> ᐧ
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] phonenum module erratic behaviour with 5.1.2

[George Diamantopoulos]

Hello all,

It seems that the phonenum module in at least 5.1.2 (haven't tried previous
versions) is behaving somewhat erratically. More specifically, if there are
any references to any phn PVs with the key other than "number":

if ( phonenum_match("1-484-555-", "src") ) {
xlog("number norm: $phn(src=>number)\n");
xlog("number country: $phn(src=>country)\n");
dbg_pv_dump(30, "L_ERR");
}

kamailio will not start:

Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: 
[core/pvapi.c:494]: pv_spec_lookup(): PV <$phn(src=>country)> is not in
cache
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: phonenum
[phonenum_pv.c:160]: pv_parse_phonenum_name(): phonenum [src] - key
[country]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: phonenum
[phonenum_pv.c:205]: pv_parse_phonenum_name(): error at PV phonenum name:
src=>country
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
[core/pvapi.c:951]: pv_parse_spec2(): pvar "phn" has an invalid name param
[src=>country]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
[core/pvapi.c:1106]: pv_parse_spec2(): wrong char [)/41] in
[$phn(src=>country)] at [17 (5)]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: xlog
[xlog.c:513]: xdbg_fixup_helper(): wrong format[number country:
$phn(src=>country)

If I comment the offending line, all is well, but when dumping PVs with
dbg_pv_dump(30, "L_ERR");, only $phn(src=>number) is listed, not the other
keys (country, operator, region according to the docs)

However, what is more disturbing is that phn(src=>number) always contains
the string provided to phonenum_match() function, even if invalid
characters are included, with no normalization. For example:

phonenum_match("14~8%^88", "src")

will result in dbg_pv_dump reporting:

"$phn(src=>number)": "14~8%^88"

Please note that I'm using sipwise's debian repository for stretch for
kamailio, and debian's stable stretch repository for libphonenumnber
(currently at 7.1.0-5+b1). I have also tried building current
libphonenumber myself (version v8.9.2), but the result is the same.

Is this a bug? Or am I missing something? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Some clarifications needed on async_task_route

[George Diamantopoulos]

Hello all,

I've been exploring the async module a little, and async_task_route() more
specifically. I have async_workers set, and the async module loaded.

However, whenever this async function is involved in SIP processing,
kamailio returns a 500 error to the UAC. I was hoping that someone could
confirm that this function is suitable for my needs, I'm not sure I
understand the docs very well on this one.

So the plan is to have some of the processing of the transaction performed
asynchronously, as it is not required for routing etc. Here's an example of
what I'm trying to achieve, it's not really critical if NICE_TO_HAVE route
functions fail etc, I just need request_route processing to continue
normally without waiting for async_task_route("NICE_TO_HAVE") to finish
whatever it's going to be doing:

request_route() {

...

SIP_PROCESSING_A

...

async_task_route("NICE_TO_HAVE")

...

SIP_PROCESSING_B

t_relay();

}

route(NICE_TO_HAVE) {

dlg_var(sth) = something_derived_from_global_vars();

}

Is this possible, or am I completely out of scope here? Thanks!

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello Daniel,

A URI param doesn't sound bad at all for this purpose, and works like a
charm! I believe the parameter never makes it to the receiving end when
using regular dispatcher functionality, as the R-URI is not rewritten and
only the $du variable is set with this URI, which never appears in the SIP
message anywhere, right? So there's some degree of elegance here as well
:-D.

Thanks again for the workaround, I've been working on this for a while...

Best regards,
George

On 20 December 2017 at 17:26, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:

> Hello,
>
> an workaround would be to add a custom parameter to the destination value,
> like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored by the
> receiving party. Or if you have only two records with same address, add to
> one ";transport=udp".
>
> Of course, coding in C to make it easier in config would be the elegant
> solution.
>
> Cheers,
> Daniel
>
> On 20.12.17 15:32, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> Thanks for the reply. Unfortunately I can't really use the database
> records to achieve what I want. The example in my previous message didn't
> show this, but I would like to be able to differentiate between the
> following:
>
> ++---+-+---+--+-
> +
> | id | setid | destination | flags | priority |
> attrs   |
> ++---+-+---+--+-
> +
> |  1 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 44.44.44.1:5060  |
> |  2 |10 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 55.55.55.1:5060  |
> ++---+-+---+--+-
> +
>
> In this case, how can I tell which destination went down? The URI is the
> same, but the sockets differ for each id.
>
> If only $ru is available in these event routes, I can't query the database
> because $ru matches both records. If I can't access the socket used with a
> PV, is there any way to have access to *either* the id *or* the setid for
> the destination for which the event was generated?
>
> Thanks!
>
> BR,
> George
>
> On 20 December 2017 at 10:57, Daniel-Constantin Mierla <mico...@gmail.com>
> wrote:
>
>> Hello,
>>
>> those event routes are executed with a so called faked request (a request
>> generated internally, unrelated to the OPTIONS request sent to the wire),
>> apart of request uri, the rest of values are not related to the dispatcher
>> records.
>>
>> To get access to other attributes of dispatcher records in a straight way
>> in the config, it would require C coding, Anyhow, even now using scripting,
>> you can try with sql queries to database or rpc commands execution via
>> jsonrpcs module and then parse the result using jansson module.
>>
>> Cheers,
>> Daniel
>>
>> On 18.12.17 13:33, George Diamantopoulos wrote:
>>
>> Hello all,
>>
>> I use the dispatcher module extensively for load balancing and fail-over.
>> My kamailio instance is multihomed, and I use the "socket" attribute to
>> determine which socket SIP messages should use for each dispatcher
>> destination, as such:
>>
>> ++---+-+---+--+-
>> +
>> | id | setid | destination | flags | priority |
>> attrs   |
>> ++---+-+---+--+-
>> +
>> |  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
>> 10.10.10.1:5060  |
>> |  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
>> 44.44.44.1:5060  |
>> |  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
>> 55.55.55.1:5060  |
>> ++---+-+---+--+-
>> +
>>
>> The dispatcher module uses OPTIONS to probe each destination for
>> availability. When a destination goes down or up, the respective
>> event-route is executed.
>>
>> What I need to do is to be able to "capture" the sending socket used for
>> this probing when a destination becomes unavailable or available in the
>> event-routes. The $fs variable is set, but unfortunately its value does not
>> make sense. Here's an example route and the results that are printed:
>>
>> event_route[dispatcher:dst-down] {
>> xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
>> $T_req($fs) $T_req($Ru)\n");
>> }
>>
>> Now say destination with id = '2' goes down. This is what I get in the
>> logs for the event_route above:
>>
>> ERROR: 

Re: [SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello Daniel,

Thanks for the reply. Unfortunately I can't really use the database records
to achieve what I want. The example in my previous message didn't show
this, but I would like to be able to differentiate between the following:

++---+-+---+--+-
+
| id | setid | destination | flags | priority |
attrs   |
++---+-+---+--+-
+
|  1 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
44.44.44.1:5060  |
|  2 |10 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
55.55.55.1:5060  |
++---+-+---+--+-
+

In this case, how can I tell which destination went down? The URI is the
same, but the sockets differ for each id.

If only $ru is available in these event routes, I can't query the database
because $ru matches both records. If I can't access the socket used with a
PV, is there any way to have access to *either* the id *or* the setid for
the destination for which the event was generated?

Thanks!

BR,
George

On 20 December 2017 at 10:57, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:

> Hello,
>
> those event routes are executed with a so called faked request (a request
> generated internally, unrelated to the OPTIONS request sent to the wire),
> apart of request uri, the rest of values are not related to the dispatcher
> records.
>
> To get access to other attributes of dispatcher records in a straight way
> in the config, it would require C coding, Anyhow, even now using scripting,
> you can try with sql queries to database or rpc commands execution via
> jsonrpcs module and then parse the result using jansson module.
>
> Cheers,
> Daniel
>
> On 18.12.17 13:33, George Diamantopoulos wrote:
>
> Hello all,
>
> I use the dispatcher module extensively for load balancing and fail-over.
> My kamailio instance is multihomed, and I use the "socket" attribute to
> determine which socket SIP messages should use for each dispatcher
> destination, as such:
>
> ++---+-+---+--+-
> +
> | id | setid | destination | flags | priority |
> attrs   |
> ++---+-+---+--+-
> +
> |  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
> 10.10.10.1:5060  |
> |  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 44.44.44.1:5060  |
> |  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
> 55.55.55.1:5060  |
> ++---+-+---+--+-
> +
>
> The dispatcher module uses OPTIONS to probe each destination for
> availability. When a destination goes down or up, the respective
> event-route is executed.
>
> What I need to do is to be able to "capture" the sending socket used for
> this probing when a destination becomes unavailable or available in the
> event-routes. The $fs variable is set, but unfortunately its value does not
> make sense. Here's an example route and the results that are printed:
>
> event_route[dispatcher:dst-down] {
> xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
> $T_req($Ru)\n");
> }
>
> Now say destination with id = '2' goes down. This is what I get in the
> logs for the event_route above:
>
> ERROR: 

[SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello all,

I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:

++---+-+---+--+-+
| id | setid | destination | flags | priority |
attrs   |
++---+-+---+--+-+
|  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
10.10.10.1:5060  |
|  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
44.44.44.1:5060  |
|  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
55.55.55.1:5060  |
++---+-+---+--+-+

The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.

What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:

event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
$T_req($Ru)\n");
}

Now say destination with id = '2' goes down. This is what I get in the logs
for the event_route above:

ERROR: 

Re: [SR-Users] Kamailio does not add port number to addresses in Via, Record-Route headers

[George Diamantopoulos]

Hello again,

Indeed this issue does not manifest at all. I'm awfully sorry for the false
alarm, and on release day no less!

The problem was there was a lingering DNAT rule in iptables, which would
translate port 5066 to port 5060. The deployment script injected this as it
was carried over from our legacy platform.

Of course, I kept banging my head against the wall here because sngrep
wouldn't show the DNAT's effect as it captures traffic from the NIC
directly: it would show a REGISTER arriving on 5066, but the dport was
masqueraded before being handed over to kamailio. Similarly for the
outgoing INVITE.

NAT is wrong in so many ways... :-)

BR,
George

On 11 December 2017 at 18:17, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:

> Hello,
>
> I did a quick test and all looks fine, ports are set in via and
> record-route, in my config I have:
>
> record_route();
>
> $fs="udp:127.0.0.1:5080";
> $du = "sip:127.0.0.1:9";
> t_relay();
> exit;
>
> Then sending an OPTIONS resulted in the trace shown below.
>
> Cheers,
> Daniel
>
> U 2017/12/11 17:14:47.108430 127.0.0.1:56729 -> 127.0.0.1:5060
> OPTIONS sip:test@127.0.0.1 SIP/2.0.
> Via: SIP/2.0/UDP 192.168.178.84:62516;branch=z9hG4bK.3aaddf68;rport;alias.
> From: sip:sipsak@192.168.178.84:62516;tag=16d1c24.
> To: sip:test@127.0.0.1.
> Call-ID: 23927844@192.168.178.84.
> CSeq: 1 OPTIONS.
> Contact: sip:sipsak@192.168.178.84:62516.
> Content-Length: 0.
> Max-Forwards: 70.
> User-Agent: sipsak 0.9.7pre.
> Accept: text/plain.
> .
>
>
> U 2017/12/11 17:14:51.010251 127.0.0.1:5080 -> 127.0.0.1:9
> OPTIONS sip:test@127.0.0.1 SIP/2.0.
> Record-Route: <sip:127.0.0.1:5080;r2=on;lr>.
> Record-Route: <sip:127.0.0.1;r2=on;lr>.
> Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK61bd.
> b2882fea15c488761489f8ef588efbe1.0.
> Via: SIP/2.0/UDP 192.168.178.84:62516;received=127.0.0.1;branch=z9hG4bK.
> 3aaddf68;rport=56729;alias.
> From: sip:sipsak@192.168.178.84:62516;tag=16d1c24.
> To: sip:test@127.0.0.1.
> Call-ID: 23927844@192.168.178.84.
> CSeq: 1 OPTIONS.
> Contact: sip:sipsak@192.168.178.84:62516.
> Content-Length: 0.
> Max-Forwards: 69.
> User-Agent: sipsak 0.9.7pre.
> Accept: text/plain.
> .
>
> On 11.12.17 16:37, George Diamantopoulos wrote:
>
> Hello all,
>
> I have the following issue in my configuration, tested with 5.2.0-rc1 so
> far:
>
> At some point, I set the $fs pseudovariable to force a request to be
> relayed through a specific socket. Although this is honoured by kamailio
> (i.e. the request does indeed leave the kamailio host from the respective
> socket), the port number is not added to the Via and RR headers. As a
> result, all replies to the request, as well as all subsequent requests from
> the other SIP UA are relayed to the default port, 5060. Here's an example:
>
> SIP UAC to kamailio:
> INVITE 192.168.1.1:5060 ---> 192.168.1.254:5060
> Kamailio to UAS ($fs is set):
> INVITE 2.2.2.2:5066 ---> 3.3.3.3:5060
> Topmost Via in request relayed by kamailio is:
> SIP/2.0/UDP 2.2.2.2;branch=aa<- port 5066 is not added
> Topmost RR in request relayed by kamailio is:
> <sip:2.2.2.2;r2=on;lr;did=bbb;nat=yes><- port 5066 is not added
> RESULT: Reply from UAS is sent to 2.2.2.2:5060
>
> Is this behaviour valid? Am I missing anything? Kamailio is configured to
> listen on both sockets on IP 2.2.2.2, namely: a) udp:2.2.2.2:5060 and b)
> 2.2.2.2:5066. Thanks.
>
> BR,
> George
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio does not add port number to addresses in Via, Record-Route headers

[George Diamantopoulos]

Hello all,

I have the following issue in my configuration, tested with 5.2.0-rc1 so
far:

At some point, I set the $fs pseudovariable to force a request to be
relayed through a specific socket. Although this is honoured by kamailio
(i.e. the request does indeed leave the kamailio host from the respective
socket), the port number is not added to the Via and RR headers. As a
result, all replies to the request, as well as all subsequent requests from
the other SIP UA are relayed to the default port, 5060. Here's an example:

SIP UAC to kamailio:
INVITE 192.168.1.1:5060 ---> 192.168.1.254:5060
Kamailio to UAS ($fs is set):
INVITE 2.2.2.2:5066 ---> 3.3.3.3:5060
Topmost Via in request relayed by kamailio is:
SIP/2.0/UDP 2.2.2.2;branch=aa<- port 5066 is not added
Topmost RR in request relayed by kamailio is:
<- port 5066 is not added
RESULT: Reply from UAS is sent to 2.2.2.2:5060

Is this behaviour valid? Am I missing anything? Kamailio is configured to
listen on both sockets on IP 2.2.2.2, namely: a) udp:2.2.2.2:5060 and b)
2.2.2.2:5066. Thanks.

BR,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using dispatcher's algorithm 12

[George Diamantopoulos]

Never mind, uac seems to ignore $du variables and only sends to uri set
with $uac_req(ruri)... Did a loop over ds_next_dst() while $du != $null and
achieved the same effect...

On 2 December 2017 at 23:32, George Diamantopoulos <georged...@gmail.com>
wrote:

> Also, what happens when two entries in the same set have the same priority
> and algorithm "8" is used? Does it round-robin among them? Or does it
> always select the first one? Thanks!
>
> On 2 December 2017 at 23:27, George Diamantopoulos <georged...@gmail.com>
> wrote:
>
>> Hello Federico,
>>
>> Thanks for the reply. I'm on 5.1.0-rc2.
>>
>> BR,
>> George
>>
>> On 2 December 2017 at 22:36, Federico Cabiddu <federico.cabi...@gmail.com
>> > wrote:
>>
>>> Hi,
>>> which Kamailio version are you using?
>>> Dispatcher's algorithm 12 is available in master/5.1-dev.
>>> The default behaviour of the module is to pick the first destination in
>>> the set if the selected algorithm is unknown: http://www.kamailio.o
>>> rg/docs/modules/5.0.x/modules/dispatcher.html#dispatcher.f.ds_select_dst
>>> .
>>>
>>> Regards,
>>>
>>> Federico
>>>
>>> On 2 Dec 2017 21:28, "George Diamantopoulos" <georged...@gmail.com>
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I've been trying to use dispatcher's algorithm "12" to fork REGISTER
>>>> messages constructed with uac module to all destinations within a set.
>>>>
>>>> However, the request is routed to only one destination. Is anything
>>>> else needed in addition to calling ds_select_dst("0", "12") in the
>>>> configuration script? Thanks.
>>>>
>>>> BR,
>>>> George
>>>>
>>>> ___
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users@lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using dispatcher's algorithm 12

[George Diamantopoulos]

Also, what happens when two entries in the same set have the same priority
and algorithm "8" is used? Does it round-robin among them? Or does it
always select the first one? Thanks!

On 2 December 2017 at 23:27, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello Federico,
>
> Thanks for the reply. I'm on 5.1.0-rc2.
>
> BR,
> George
>
> On 2 December 2017 at 22:36, Federico Cabiddu <federico.cabi...@gmail.com>
> wrote:
>
>> Hi,
>> which Kamailio version are you using?
>> Dispatcher's algorithm 12 is available in master/5.1-dev.
>> The default behaviour of the module is to pick the first destination in
>> the set if the selected algorithm is unknown: http://www.kamailio.o
>> rg/docs/modules/5.0.x/modules/dispatcher.html#dispatcher.f.ds_select_dst.
>>
>> Regards,
>>
>> Federico
>>
>> On 2 Dec 2017 21:28, "George Diamantopoulos" <georged...@gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I've been trying to use dispatcher's algorithm "12" to fork REGISTER
>>> messages constructed with uac module to all destinations within a set.
>>>
>>> However, the request is routed to only one destination. Is anything else
>>> needed in addition to calling ds_select_dst("0", "12") in the configuration
>>> script? Thanks.
>>>
>>> BR,
>>> George
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using dispatcher's algorithm 12

[George Diamantopoulos]

Hello Federico,

Thanks for the reply. I'm on 5.1.0-rc2.

BR,
George

On 2 December 2017 at 22:36, Federico Cabiddu <federico.cabi...@gmail.com>
wrote:

> Hi,
> which Kamailio version are you using?
> Dispatcher's algorithm 12 is available in master/5.1-dev.
> The default behaviour of the module is to pick the first destination in
> the set if the selected algorithm is unknown: http://www.kamailio.
> org/docs/modules/5.0.x/modules/dispatcher.html#dispatcher.f.ds_select_dst.
>
> Regards,
>
> Federico
>
> On 2 Dec 2017 21:28, "George Diamantopoulos" <georged...@gmail.com> wrote:
>
>> Hello all,
>>
>> I've been trying to use dispatcher's algorithm "12" to fork REGISTER
>> messages constructed with uac module to all destinations within a set.
>>
>> However, the request is routed to only one destination. Is anything else
>> needed in addition to calling ds_select_dst("0", "12") in the configuration
>> script? Thanks.
>>
>> BR,
>> George
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] "Federated" PBX solution with GUI to use with Kamailio - Suggestions needed

[George Diamantopoulos]

Hello all!

I'm looking at "PBX" platforms to use with kamailio as a load-balancer.
This is not a strictly kamailio question, but I thought that if anyone has
a suggestion to make, they would be watching this list.

I'm investigating a use case with the following requirements:
* Kamailio will act as a load-balancer, dispatching initial requests to PBX
entities (e.g. Asterisk, Freeswitch)
* PBX solution must have a single GUI interface to manage PBX functions
(think FreePBX, FusionPBX etc)
* Configuration via the GUI must apply to all PBX instances
* Some sort of "asterisk-realtime + device state synchronization"-like
setup must ensure every PBX box can service any request at any time (for
failover)
* Solution needn't be multi-tenant oriented, but if it is, it must work
fine for single-tenant setups as well without multi-tenant capability
getting in the way all the time
* Feature list needn't be as full as, say, FreePBX's, but most common
functionality must be available (inbound/outbound routing, trunks, queues,
hunting to name a few)
* Must be open source

As a proprietary example, MiRTA PBX seems to check all the boxes above,
apart from being open source. Now this "product" also offers high
availability for databases and web apps, which is beyond the scope of this
investigation. I'm only looking at a solution that provides a federated,
synchronized farm of PBX instances.

Any input would be greatly appreciated. Thanks!

Best regards,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Testing for user=phone with siputils uri_param() doesn't work

[George Diamantopoulos]

Hello Daniel!

Thanks for the reply. Here's the first line of a request where uri_param()
fails to detect user=phone is already present. IPs, phone numbers and
domains have been censored, but most properties (number of parts, length
etc) have been preserved where possible:

INVITE sip:+30697400@2.2.2.2;user=phone SIP/2.0

The example code in my original message results in the following (the
script also replaces the domain part and adds the npdi username parameter):

INVITE sip:+30697400;n...@my.domain.tld;user=phone;user=phone SIP/2.0

BR,
George

On 23 October 2017 at 10:22, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:

> Hello,
>
>
> On 13.10.17 17:25, George Diamantopoulos wrote:
> > Hello,
> >
> > In my script I've had to test for the user=phone parameter in URIs. I
> > thought uri_param() from siputils would be handy for this operation on
> > the RURI, so I did:
> >
> > if ( !uri_param("user","phone") ) {
> > add_uri_param("user=phone");
> > }
> >
> > Unfortunately this wouldn't work (uri_param returns -1), and I end up
> > with double user=phone params in the RURI.
> >
> > I was able to work around this by changing the test to:
> >
> > if ( !($(ru{uri.uparam}) == "phone") ) {
> > add_uri_param("user=phone");
> > }
> >
> > But I wanted to ask if this is intentional or if I should file a bug
> > or something. Thanks.
> >
> according to the docs, uri_param() should work for this case. Can you
> paste the first line of the request that fails with uri_param() function
> so I can look at the code and see if there is any issue there?
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Hello,

No, I gave up in the end. Fortunately I was able to do what I needed with
policy-based routing, which is not the same as VRF, but it did the trick in
my scenario...

BR,
George

On 14 October 2017 at 01:22, Marrold  wrote:

> Hi George,
>
> Did you have any luck getting VRFs working with Kamailio?
>
> Thanks
>
> Matthew
>
> On Thu, Oct 12, 2017 at 8:06 PM, Mark Boyce  wrote:
>
>> Hi
>>
>> I *think* I may have found it … although still not sure what’s doing the
>> filtering.
>>
>> If I force the sending IP to be the the VPN interface on the sender by
>> adding;
>>
>> modparam("siptrace", "force_send_sock", "sip:10.0.0.2:5060”)
>>
>> So packets now arrive at the receiver from the 10. IP rather than from
>> the public IP of the sender
>>
>> … and magically it starts working.
>>
>> So something in Ubuntu 16.04 / zerotier is “filtering” packets which
>> arrive on the VPN interface but with a no VPN IP
>>
>> Cheers
>>
>> Mark
>>
>>
>> On 12 Oct 2017, at 19:59, Sergey Safarov  wrote:
>>
>> This may be NAT/iptables issue if used some type of virtualization
>> Check UNDEPLIED connection using conntrack
>>
>> Sergey
>>
>> чт, 12 окт. 2017 г. в 20:27, Mark Boyce :
>>
>>> Hi
>>>
>>> Now using listen=udp:0.0.0.0:9060
>>>
>>> net stat agrees;
>>>
>>> netstat -plunt | grep kamailio
>>> udp0  0 0.0.0.0:90600.0.0.0:*
>>> 20486/kamailio
>>>
>>>
>>> TCPDump of Sending / Receiving to zero tier port
>>>
>>> 17:06:19.617467 IP sbc-1.white-label.com.sip > 10.0.0.1.9060: SIP
>>> 0x:  4510 04f1 a504  4011 904e 894a abd8  E...@
>>> ..N.J..
>>> 0x0010:  0a05 0172 13c4 2364 04dd 261b 0110
>>> 0211  ...r..#d..&.
>>> 0x0020:  13c4 13d8 894a abd8 894a abd8 494e
>>> 5649  .J...J..INVI
>>> 0x0030:  5445 2073 6970 3a32 4073 6263 2d31 2e77  TE.sip:
>>> 2@sbc-1.w
>>>
>>> Nothing in Kamailio Logs
>>>
>>> Swap to using the real IP and I’m seeing the log line from the top of
>>> the main route;
>>>
>>> Oct 12 19:09:32 vps465590 homer[20491]: ERROR: 

[SR-Users] Testing for user=phone with siputils uri_param() doesn't work

[George Diamantopoulos]

Hello,

In my script I've had to test for the user=phone parameter in URIs. I
thought uri_param() from siputils would be handy for this operation on the
RURI, so I did:

if ( !uri_param("user","phone") ) {
add_uri_param("user=phone");
}

Unfortunately this wouldn't work (uri_param returns -1), and I end up with
double user=phone params in the RURI.

I was able to work around this by changing the test to:

if ( !($(ru{uri.uparam}) == "phone") ) {
add_uri_param("user=phone");
}

But I wanted to ask if this is intentional or if I should file a bug or
something. Thanks.
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Just one last thing, are you absolutely certain there's no firewall doing
the damage there? It's quite common for firewall-blocked traffic to show up
with tcpdump, but never reach the application...

On 12 October 2017 at 20:26, Mark Boyce  wrote:

> Hi
>
> Now using listen=udp:0.0.0.0:9060
>
> net stat agrees;
>
> netstat -plunt | grep kamailio
> udp0  0 0.0.0.0:90600.0.0.0:*
>   20486/kamailio
>
>
> TCPDump of Sending / Receiving to zero tier port
>
> 17:06:19.617467 IP sbc-1.white-label.com.sip > 10.0.0.1.9060: SIP
> 0x:  4510 04f1 a504  4011 904e 894a abd8  E...@..N.J..
> 0x0010:  0a05 0172 13c4 2364 04dd 261b 0110 0211  ...r..#d..&.
> 0x0020:  13c4 13d8 894a abd8 894a abd8 494e 5649  .J...J..INVI
> 0x0030:  5445 2073 6970 3a32 4073 6263 2d31 2e77  TE.sip:2@sbc-1.w
>
> Nothing in Kamailio Logs
>
> Swap to using the real IP and I’m seeing the log line from the top of the
> main route;
>
> Oct 12 19:09:32 vps465590 homer[20491]: ERROR: 

Re: [SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Hmm... Everything looks fine indeed, I can't see any obvious reason why
this isn't working...

Just to be clear, have you tried listening on all interfaces:
listen=udp:0.0.0.0:9060

And if yes, can you capture traffic arriving on the ZeroTier interface in
this case? If it works, is there any reason why listening on all interfaces
is not acceptable in your use case?

Regardless, it might be a good idea to start a new thread about this, maybe
it's related to the inner workings of the ZeroTier device and how it
interacts with the kernel...


On 12 October 2017 at 18:26, Mark Boyce <m...@darkorigins.com> wrote:

> Hi George
>
> (IP / MACs below anonymised a bit)
>
>
> I’m working on a https://www.zerotier.com VPN endpoint which presents as
> a new interface;
>
>
> Real Interface
>
> ens3  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
>   inet addr: 1.2.3.4  Bcast: 1.2.3.4  Mask:255.255.255.255
>   inet6 addr: a:::::/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:12978431 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11331437 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:2508723344 (2.5 GB)  TX bytes:1149701606 (1.1 GB)
>
> loopback
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:58936 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:58936 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:12470726 (12.4 MB)  TX bytes:12470726 (12.4 MB)
>
> ZeroTier
>
> zt0   Link encap:Ethernet  HWaddr yy:yy:yy:yy:yy:yy
>   inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:2800  Metric:1
>   RX packets:11148 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1113 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:3760555 (3.7 MB)  TX bytes:584324 (584.3 KB)
>
>
> This is actually a SIPCapture/Homer node so the config is;
>
> modparam("sipcapture", "capture_on", 1)
> modparam("sipcapture", "hep_capture_on", 1)
> listen=udp:10.0.0.1:9060
>
> The port bind looks ok;
>
> # netstat -plunt | grep kamailio
> udp0  0 10.0.0.1:9060 0.0.0.0:*
> 19592/kamailio
>
>
> I’m tracking packets at the top of "route {“
>
> route {
> xlog("route entered\r\n”);
>
>
>
> If I tcpdump the ZeroTier Interface ;
>
> tcpdump -i zt0 -p -X  port 9060
>
> 15:08:38.556323 IP sbc-1.white-label.com.sip > 10.0.0.1.9060: SIP
> 0x:  4510 0181 7883  4011 c03f 894a abd8  E...x...@..?.J..
> 0x0010:  0a05 0172 13c4 2364 016d e2e2 0110 0216  ...r..#d.m..
> 0x0020:  07a8 13c5 5c17 3523 894a abd8 4143 4b20  \.5#.J..ACK.
>
>
> … but nothing seen in kamailio.
>
> If I swap over to sending to / listening on the public IP everything works
> as expected.
>
>
>
> Cheers
> Mark
>
>
> On 12 Oct 2017, at 15:56, George Diamantopoulos <georged...@gmail.com>
> wrote:
>
> Hello,
>
> That seems strange... What kind of device is that VPN device? Like a ppp0
> interface? What is the output of "netstat -plunt | grep kamailio"? Are you
> using a "private" IP for the VPN interface and what's your main routing
> table like?
>
> Also what if you omit the "listen" directive in kamailio configuration?
> Does it listen on the VPN interface then? Kamailio will bind by default to
> all interfaces if no "listen" directive is used...
>
> On 12 October 2017 at 00:26, Mark Boyce <m...@darkorigins.com> wrote:
>
>> Hi All
>>
>> Just to dive in here with something which may be related.  I was about to
>> do a post with a much simpler problem where I have one real NIC and one VPN
>> created NIC.  If I listen to the public IP all’s well.  If I listen to the
>> IP of the VPN NIC Kamailio doesn’t see any traffic.   I can tcpdump on
>> either NIC and see the traffic arriving.
>>
>> Anyone seen / solved this before?
>>
>> Cheers
>> Mark
>>
>> On 11 Oct 2017, at 22:07, George Diamantopoulos <georged...@gmail.com>
>> wrote:
>>
>> Hello Daniel,
>>
>> I'm including the original sketch for clarity:
>>
>>  +--+  +---+
>>  |   eth0   |  |vrf-green  |
>>

Re: [SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Hello Daniel,

I'm including the original sketch for clarity:

 +--+  +---+
 |   eth0   |  |vrf-green  |
 | 1.1.1.1  |  |127.0.0.1  |
 +--+  +---+
|
  +--+
  |   eth1   |
  | 2.2.2.2  |
  +--+

Thanks for the reply. Indeed, using the advertise option for the "listen"
directive will result in kamaiio no longer failing to start when using
force_send_socket(2.2.2.2:5060) with 2.2.2.2 being used in the "advertise"
option.

However, this doesn't make much of a difference in that kamailio still
won't process IP packets arriving on eth1 at IP 2.2.2.2... I can see
OPTIONS coming with sngrep, but nothing in the logs, no replies, only
retransmissions from the originator.
In addition, while without VRF kamailio will select the right interface
with mhomed=1, this is no longer the case.
Also, If I try to send something to a host with force_send_socket, the
transaction fails with 477 Unfortunately error on sending to next hop
occurred. In the log, kamailio prints something along the lines of:
udp_send(): sendto(sock,0x7f5c4f937d08,1888,0,9.9.9.9:5060,16): Invalid
argument(22)
udp_send(): invalid sendtoparameters
msg_send_buffer(): udp_send failed
where 9.9.9.9 is the $dd and presumably force_send_socket(2.2.2.2:5060) has
been called before t_relay()

Also, I additionally found out that if the networking configuration is as
follows:

 +--+  +---+   +---+
 |   eth0   |  |vrf-green  |   |vrf-red|
 | 1.1.1.1  |  |127.0.0.1  |   |127.0.0.1  |
 +--+  +---+   +---+
|   |
  +--++--+
  |   eth1   ||   eth2   |
  | 2.2.2.2  || 3.3.3.3  |
  +--++--+

Then this won't work for vrf-red:
listen=vrf-green:5060 advertise 2.2.2.2:5060
listen=vrf-red:5060 advertise 3.3.3.3:5060
One needs to use different IPs for the MASTER devices (say 127.0.0.1 and
127.0.0.2) for kamailio to startup with the above listen directives.

It's a bit surprising it doesn't work. According to a user on cumulus slack
channel (cumulus contributed the VRF code to the linux kernel): "any app
that has a command line or option switch to call SO_BINDTODEVICE on the
sockets can be configured to use any VRF".

I guess the problem lies in that kamailio binds to several sockets and
there are multiple routing tables to consult, so mhomed doesn't work as
expected (if every table has a default route and nothing more specific than
that). But still, this doesn't really explain why binding to the VRF master
net devices doesn't work (I mean, "ping -I vrf-green" works just fine for
ping)...

I don't think VRF support is very useful for most users though, I just had
one corner case I needed to tackle and VRF seemed like an easy fix. I'll
think of an alternative at some point, I guess.

On 26 September 2017 at 09:52, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:
>
> Hello,
>
> I haven't worked with vrf here, so no first hand experience ...
>
> What happens if you try with next option?
>
> listen=vrf-green:5060 advertise 2.2.2.2:5060
>
> Cheers,
> Daniel
>
>
> On 25.09.17 19:10, George Diamantopoulos wrote:
>
> Sorry to bump this, but it would be very useful if I knew whether there's
any point in pursuing this or not. Any hints?
>
> On 21 September 2017 at 14:06, George Diamantopoulos <georged...@gmail.com>
wrote:
>>
>> Hello,
>>
>> I have a use case where I need to have kamailio bind to a VRF device.
The configuration in question is similar to the example below, where eth1
is a slave to the VRF-lite device:
>>
>>  +--+  +---+
>>  |   eth0   |  |vrf-green  |
>>  | 1.1.1.1  |  |127.0.0.1  |
>>  +--+  +---+
>> |
>>   +--+
>>   |   eth1   |
>>   | 2.2.2.2  |
>>   +--+
>>
>> Both the main routing table and "vrf-green" routing table have a default
route.
>>
>> What I need to be able to do is have kamailio bind to both interfaces:
>>
>> listen=eth0:5060
>> listen=vrf-green:5060
>>
>> And additionally be able to use force_send_socket to select an
interface, for example:
>>
>> force_send_socket(udp:2.2.2.2:5060);
>>
>> However, I can't get this to work. The above configuration

Re: [SR-Users] Kamailio htable mod-init route: Main process exited before writing to pipe

[George Diamantopoulos]

Never mind, I'm certain by now:

http://sip-router.1086192.n5.nabble.com/DB-select-htable-mod-init-doesn-t-work-td127717.html
https://lists.kamailio.org/pipermail/sr-dev/2013-February/018484.html

On 28 September 2017 at 22:18, George Diamantopoulos <georged...@gmail.com>
wrote:

> Also, I' found this post by Daniel in 2014:
>
> https://lists.kamailio.org/pipermail/sr-users/2014-May/083155.html
>
> To quote:
> > Indeed, the db connection is not initialized at the time of executing
> > event_route[htable:mod-init]. This is executed after all modules are
> > initialized, but the sqlops connections are initialized in child init.
>
> So maybe this is the case for 5.0.3 as well? sqlops functions can't be
> used in event_route[htable:mod-init] yet?
>
>
> On 28 September 2017 at 20:18, George Diamantopoulos <georged...@gmail.com
> > wrote:
>
>> Hello,
>>
>> I've tested again, this time including a single sql_pvquery function in
>> the event-route. Kamailio will also exit with "daemonize(): Main process
>> exited before writing to pipe" in this simpler case.
>>
>> In the documentation, it is stated that: The event route is executed only
>> once, after core and module initialization, but before Kamailio
>> forks any child processes.
>>
>> Does this mean that I don't have (perhaps) access to pseudovariables during 
>> execution of this route? Is this the reason why kamailio exits prematurely?
>>
>> Thanks,
>>
>> George
>>
>>
>> On 26 September 2017 at 15:37, George Diamantopoulos <
>> georged...@gmail.com> wrote:
>>
>>> I forgot to mention, I'm using Kamailio 5.0.3 on debian "stretch".
>>>
>>> On 26 September 2017 at 14:40, George Diamantopoulos <
>>> georged...@gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I've been trying to utilise event_route[htable:mod-init] in order to
>>>> load information from the database into an htable on startup. However,
>>>> Kamailio exits with an error for no obvious (to me) reason. Here's the log
>>>> output:
>>>>
>>>> DEBUG: htable [htable.c:226]: child_init(): rank is (-127)
>>>> DEBUG: htable [htable.c:259]: child_init(): executing
>>>> event_route[htable:mod-init] (2)
>>>> DEBUG:  [core/parser/msg_parser.c:600]: parse_msg(): SIP Request:
>>>> DEBUG:  [core/parser/msg_parser.c:602]: parse_msg():  method:
>>>> 
>>>> DEBUG:  [core/parser/msg_parser.c:604]: parse_msg():  uri: <
>>>> sip:y...@kamailio.org>
>>>> DEBUG:  [core/parser/msg_parser.c:606]: parse_msg():  version:
>>>> 
>>>> DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of
>>>> header reached, state=2
>>>> DEBUG:  [core/parser/msg_parser.c:491]: parse_headers(): Via
>>>> found, flags=2
>>>> DEBUG:  [core/parser/msg_parser.c:493]: parse_headers(): this is
>>>> the first via
>>>> ERROR:  [core/daemonize.c:303]: daemonize(): Main process exited
>>>> before writing to pipe
>>>>
>>>> And here's the routing block in kamailio.cfg. What I need to do is get
>>>> the username for all non-expired contacts in the "location" table, perform
>>>> a query on another database for each one of them and store the result in an
>>>> htable:
>>>>
>>>> event_route[htable:mod-init] {
>>>>
>>>> sql_pvquery("ck", "select username from location where now() <=
>>>> expires", "$avp(registered_ng)");
>>>>
>>>> $var(i) = 0;
>>>> while ( $(avp(registered_ng)[$var(i)]) != $null ) {
>>>> sql_pvquery("ca", "select property from tablename where
>>>> username = $(avp(registered_ng)[$var(i)])", "$var(ng_property)");
>>>> $sht(isnguser=>$var(ng_property)) = 1;
>>>> $var(i) = $var(i) + 1;
>>>> pv_unset("$var(ng_property)");
>>>> }
>>>>
>>>> pv_unset("$var(i)");
>>>> }
>>>>
>>>> Any hints as to what I might be doing wrong? Thanks!
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>
>>>
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio htable mod-init route: Main process exited before writing to pipe

[George Diamantopoulos]

Also, I' found this post by Daniel in 2014:

https://lists.kamailio.org/pipermail/sr-users/2014-May/083155.html

To quote:
> Indeed, the db connection is not initialized at the time of executing
> event_route[htable:mod-init]. This is executed after all modules are
> initialized, but the sqlops connections are initialized in child init.

So maybe this is the case for 5.0.3 as well? sqlops functions can't be used
in event_route[htable:mod-init] yet?

On 28 September 2017 at 20:18, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello,
>
> I've tested again, this time including a single sql_pvquery function in
> the event-route. Kamailio will also exit with "daemonize(): Main process
> exited before writing to pipe" in this simpler case.
>
> In the documentation, it is stated that: The event route is executed only
> once, after core and module initialization, but before Kamailio
> forks any child processes.
>
> Does this mean that I don't have (perhaps) access to pseudovariables during 
> execution of this route? Is this the reason why kamailio exits prematurely?
>
> Thanks,
>
> George
>
>
> On 26 September 2017 at 15:37, George Diamantopoulos <georged...@gmail.com
> > wrote:
>
>> I forgot to mention, I'm using Kamailio 5.0.3 on debian "stretch".
>>
>> On 26 September 2017 at 14:40, George Diamantopoulos <
>> georged...@gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I've been trying to utilise event_route[htable:mod-init] in order to
>>> load information from the database into an htable on startup. However,
>>> Kamailio exits with an error for no obvious (to me) reason. Here's the log
>>> output:
>>>
>>> DEBUG: htable [htable.c:226]: child_init(): rank is (-127)
>>> DEBUG: htable [htable.c:259]: child_init(): executing
>>> event_route[htable:mod-init] (2)
>>> DEBUG:  [core/parser/msg_parser.c:600]: parse_msg(): SIP Request:
>>> DEBUG:  [core/parser/msg_parser.c:602]: parse_msg():  method:
>>> 
>>> DEBUG:  [core/parser/msg_parser.c:604]: parse_msg():  uri: <
>>> sip:y...@kamailio.org>
>>> DEBUG:  [core/parser/msg_parser.c:606]: parse_msg():  version:
>>> 
>>> DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of
>>> header reached, state=2
>>> DEBUG:  [core/parser/msg_parser.c:491]: parse_headers(): Via
>>> found, flags=2
>>> DEBUG:  [core/parser/msg_parser.c:493]: parse_headers(): this is
>>> the first via
>>> ERROR:  [core/daemonize.c:303]: daemonize(): Main process exited
>>> before writing to pipe
>>>
>>> And here's the routing block in kamailio.cfg. What I need to do is get
>>> the username for all non-expired contacts in the "location" table, perform
>>> a query on another database for each one of them and store the result in an
>>> htable:
>>>
>>> event_route[htable:mod-init] {
>>>
>>> sql_pvquery("ck", "select username from location where now() <=
>>> expires", "$avp(registered_ng)");
>>>
>>> $var(i) = 0;
>>> while ( $(avp(registered_ng)[$var(i)]) != $null ) {
>>> sql_pvquery("ca", "select property from tablename where username
>>> = $(avp(registered_ng)[$var(i)])", "$var(ng_property)");
>>> $sht(isnguser=>$var(ng_property)) = 1;
>>> $var(i) = $var(i) + 1;
>>> pv_unset("$var(ng_property)");
>>> }
>>>
>>> pv_unset("$var(i)");
>>> }
>>>
>>> Any hints as to what I might be doing wrong? Thanks!
>>>
>>> Best regards,
>>> George
>>>
>>
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio htable mod-init route: Main process exited before writing to pipe

[George Diamantopoulos]

Hello,

I've tested again, this time including a single sql_pvquery function in the
event-route. Kamailio will also exit with "daemonize(): Main process exited
before writing to pipe" in this simpler case.

In the documentation, it is stated that: The event route is executed only
once, after core and module initialization, but before Kamailio
forks any child processes.

Does this mean that I don't have (perhaps) access to pseudovariables
during execution of this route? Is this the reason why kamailio exits
prematurely?

Thanks,

George


On 26 September 2017 at 15:37, George Diamantopoulos <georged...@gmail.com>
wrote:

> I forgot to mention, I'm using Kamailio 5.0.3 on debian "stretch".
>
> On 26 September 2017 at 14:40, George Diamantopoulos <georged...@gmail.com
> > wrote:
>
>> Hello all,
>>
>> I've been trying to utilise event_route[htable:mod-init] in order to load
>> information from the database into an htable on startup. However, Kamailio
>> exits with an error for no obvious (to me) reason. Here's the log output:
>>
>> DEBUG: htable [htable.c:226]: child_init(): rank is (-127)
>> DEBUG: htable [htable.c:259]: child_init(): executing
>> event_route[htable:mod-init] (2)
>> DEBUG:  [core/parser/msg_parser.c:600]: parse_msg(): SIP Request:
>> DEBUG:  [core/parser/msg_parser.c:602]: parse_msg():  method:
>> 
>> DEBUG:  [core/parser/msg_parser.c:604]: parse_msg():  uri: <
>> sip:y...@kamailio.org>
>> DEBUG:  [core/parser/msg_parser.c:606]: parse_msg():  version:
>> 
>> DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of header
>> reached, state=2
>> DEBUG:  [core/parser/msg_parser.c:491]: parse_headers(): Via
>> found, flags=2
>> DEBUG:  [core/parser/msg_parser.c:493]: parse_headers(): this is
>> the first via
>> ERROR:  [core/daemonize.c:303]: daemonize(): Main process exited
>> before writing to pipe
>>
>> And here's the routing block in kamailio.cfg. What I need to do is get
>> the username for all non-expired contacts in the "location" table, perform
>> a query on another database for each one of them and store the result in an
>> htable:
>>
>> event_route[htable:mod-init] {
>>
>> sql_pvquery("ck", "select username from location where now() <=
>> expires", "$avp(registered_ng)");
>>
>> $var(i) = 0;
>> while ( $(avp(registered_ng)[$var(i)]) != $null ) {
>> sql_pvquery("ca", "select property from tablename where username
>> = $(avp(registered_ng)[$var(i)])", "$var(ng_property)");
>> $sht(isnguser=>$var(ng_property)) = 1;
>> $var(i) = $var(i) + 1;
>> pv_unset("$var(ng_property)");
>> }
>>
>> pv_unset("$var(i)");
>> }
>>
>> Any hints as to what I might be doing wrong? Thanks!
>>
>> Best regards,
>> George
>>
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio htable mod-init route: Main process exited before writing to pipe

[George Diamantopoulos]

I forgot to mention, I'm using Kamailio 5.0.3 on debian "stretch".

On 26 September 2017 at 14:40, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello all,
>
> I've been trying to utilise event_route[htable:mod-init] in order to load
> information from the database into an htable on startup. However, Kamailio
> exits with an error for no obvious (to me) reason. Here's the log output:
>
> DEBUG: htable [htable.c:226]: child_init(): rank is (-127)
> DEBUG: htable [htable.c:259]: child_init(): executing
> event_route[htable:mod-init] (2)
> DEBUG:  [core/parser/msg_parser.c:600]: parse_msg(): SIP Request:
> DEBUG:  [core/parser/msg_parser.c:602]: parse_msg():  method:
> 
> DEBUG:  [core/parser/msg_parser.c:604]: parse_msg():  uri: <
> sip:y...@kamailio.org>
> DEBUG:  [core/parser/msg_parser.c:606]: parse_msg():  version:
> 
> DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of header
> reached, state=2
> DEBUG:  [core/parser/msg_parser.c:491]: parse_headers(): Via found,
> flags=2
> DEBUG:  [core/parser/msg_parser.c:493]: parse_headers(): this is
> the first via
> ERROR:  [core/daemonize.c:303]: daemonize(): Main process exited
> before writing to pipe
>
> And here's the routing block in kamailio.cfg. What I need to do is get the
> username for all non-expired contacts in the "location" table, perform a
> query on another database for each one of them and store the result in an
> htable:
>
> event_route[htable:mod-init] {
>
> sql_pvquery("ck", "select username from location where now() <=
> expires", "$avp(registered_ng)");
>
> $var(i) = 0;
> while ( $(avp(registered_ng)[$var(i)]) != $null ) {
> sql_pvquery("ca", "select property from tablename where username =
> $(avp(registered_ng)[$var(i)])", "$var(ng_property)");
> $sht(isnguser=>$var(ng_property)) = 1;
> $var(i) = $var(i) + 1;
> pv_unset("$var(ng_property)");
> }
>
> pv_unset("$var(i)");
> }
>
> Any hints as to what I might be doing wrong? Thanks!
>
> Best regards,
> George
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio htable mod-init route: Main process exited before writing to pipe

[George Diamantopoulos]

Hello all,

I've been trying to utilise event_route[htable:mod-init] in order to load
information from the database into an htable on startup. However, Kamailio
exits with an error for no obvious (to me) reason. Here's the log output:

DEBUG: htable [htable.c:226]: child_init(): rank is (-127)
DEBUG: htable [htable.c:259]: child_init(): executing
event_route[htable:mod-init] (2)
DEBUG:  [core/parser/msg_parser.c:600]: parse_msg(): SIP Request:
DEBUG:  [core/parser/msg_parser.c:602]: parse_msg():  method:

DEBUG:  [core/parser/msg_parser.c:604]: parse_msg():  uri: <
sip:y...@kamailio.org>
DEBUG:  [core/parser/msg_parser.c:606]: parse_msg():  version:

DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of header
reached, state=2
DEBUG:  [core/parser/msg_parser.c:491]: parse_headers(): Via found,
flags=2
DEBUG:  [core/parser/msg_parser.c:493]: parse_headers(): this is the
first via
ERROR:  [core/daemonize.c:303]: daemonize(): Main process exited
before writing to pipe

And here's the routing block in kamailio.cfg. What I need to do is get the
username for all non-expired contacts in the "location" table, perform a
query on another database for each one of them and store the result in an
htable:

event_route[htable:mod-init] {

sql_pvquery("ck", "select username from location where now() <=
expires", "$avp(registered_ng)");

$var(i) = 0;
while ( $(avp(registered_ng)[$var(i)]) != $null ) {
sql_pvquery("ca", "select property from tablename where username =
$(avp(registered_ng)[$var(i)])", "$var(ng_property)");
$sht(isnguser=>$var(ng_property)) = 1;
$var(i) = $var(i) + 1;
pv_unset("$var(ng_property)");
}

pv_unset("$var(i)");
}

Any hints as to what I might be doing wrong? Thanks!

Best regards,
George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Sorry to bump this, but it would be very useful if I knew whether there's
any point in pursuing this or not. Any hints?

On 21 September 2017 at 14:06, George Diamantopoulos <georged...@gmail.com>
wrote:

> Hello,
>
> I have a use case where I need to have kamailio bind to a VRF device. The
> configuration in question is similar to the example below, where eth1 is a
> slave to the VRF-lite device:
>
>  +--+  +---+
>  |   eth0   |  |vrf-green  |
>  | 1.1.1.1  |  |127.0.0.1  |
>  +--+  +---+
> |
>   +--+
>   |   eth1   |
>   | 2.2.2.2  |
>   +--+
>
> Both the main routing table and "vrf-green" routing table have a default
> route.
>
> What I need to be able to do is have kamailio bind to both interfaces:
>
> listen=eth0:5060
> listen=vrf-green:5060
>
> And additionally be able to use force_send_socket to select an interface,
> for example:
>
> force_send_socket(udp:2.2.2.2:5060);
>
> However, I can't get this to work. The above configuration fails because
> there is no listen directive for 2.2.2.2. Also, kamailio doesn't process
> packets received on the VRF with the above listen directives, it behaves as
> if it doesn't listen on 2.2.2.2 indeed.
>
> In addition using either of the below:
>
> listen=udp:2.2.2.2:5060
> or
> listen=eth1:5060
>
> fails with an error upon starting kamailio.
>
> According to the kernel documentation:
>
> Applications that are to work within a VRF need to bind their socket to the
> VRF device:
>
> setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
>
> or to specify the output device using cmsg and IP_PKTINFO.
>
> The question is, is VRF useable with kamailio right now? Or is development 
> needed? Thanks!
>
> BR,
>
> George
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Having kamailio bind to a VRF device

[George Diamantopoulos]

Hello,

I have a use case where I need to have kamailio bind to a VRF device. The
configuration in question is similar to the example below, where eth1 is a
slave to the VRF-lite device:

 +--+  +---+
 |   eth0   |  |vrf-green  |
 | 1.1.1.1  |  |127.0.0.1  |
 +--+  +---+
|
  +--+
  |   eth1   |
  | 2.2.2.2  |
  +--+

Both the main routing table and "vrf-green" routing table have a default
route.

What I need to be able to do is have kamailio bind to both interfaces:

listen=eth0:5060
listen=vrf-green:5060

And additionally be able to use force_send_socket to select an interface,
for example:

force_send_socket(udp:2.2.2.2:5060);

However, I can't get this to work. The above configuration fails because
there is no listen directive for 2.2.2.2. Also, kamailio doesn't process
packets received on the VRF with the above listen directives, it behaves as
if it doesn't listen on 2.2.2.2 indeed.

In addition using either of the below:

listen=udp:2.2.2.2:5060
or
listen=eth1:5060

fails with an error upon starting kamailio.

According to the kernel documentation:

Applications that are to work within a VRF need to bind their socket to the
VRF device:

setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);

or to specify the output device using cmsg and IP_PKTINFO.

The question is, is VRF useable with kamailio right now? Or is
development needed? Thanks!

BR,

George
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users