[SR-Users] Re: Clarification of 'return false' behaviour
Thanks Henning and Daniel for taking the time to check this out!
I will double check my env but anyway will review my script and follow
Daniel's recommendations!
Hennig, would you be able to disclose the contents of your /root/sip3.txt
file? It really got my interest in this nc usage!
Appreciate your replies!
Kind regards,
Patrick
On Tue, 2 May 2023 at 18:10, Daniel-Constantin Mierla
wrote:
> Hello,
>
> indeed, it is somehow confusing, because in terms of evaluating the return
> code in logical expression, 'false' means the return code was negative and
> 'true' means it was positve.
>
> Then the core keywords 'true' and 'false' are just aliases to 1 and 0 for
> use with core parameters, but their meaning is not related to logical
> evaluation of function's return code.
>
> Someone decided like 20 years ago to have this kind of logical evaluation
> and it continued to be like that till now.
>
> There was a regression at some point when return 0 was no longer exiting,
> being fixed at some point. One may notice the behaviour change if run same
> config before and after.
>
> In general is not good to just return the value from execution of a
> function, but evaluate to true or false and return explicitly own values.
> Instead of
>
> return x()
>
> do:
>
> if(x()) {
>
> return 1;
>
> } else {
>
> return -1;
>
> }
>
> Cheers,
> Daniel
> On 01.05.23 01:10, Patrick Wakano wrote:
>
> Thanks very much for the clarification Daniel! Appreciate it!
> However it does seem that some modules have inconsistencies with return
> values now. So, for instance, the is_ip_rfc918() says it will return true
> or false (
> https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
> - most functions of this module return true or false) and then when used
> directly with return, it terminates execution. Based on your explanation,
> it shouldn't return true or false, but likely -1 or 1, which would never be
> considered 'return 0'
> Also, the below code works in version 5.4, but terminates execution in
> version 5.6, so are you aware of changes in this behaviour in version 5.5
> or 5.6 (before the 5.7 changes you mentioned)?
> route[is_src_private]
> {
> return is_ip_rfc1918("$si");
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
>
> Best regards!
> Patrick
>
> On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
> wrote:
>
>> Hello,
>>
>> false is 0 and it was actually designed for setting global parameters,
>> not for use as comparison with functions return code or as parameter for
>> return from route blocks. Like:
>>
>> log_stderror = false
>>
>> The grammar of the language defines a coupe of token variants for same
>> purpose:
>>
>>
>>YES "yes"|"true"|"on"|"enable"
>>NO "no"|"false"|"off"|"disable"
>>
>> Where YES is replaced by 1 and NO is replaced by 0:
>>
>>{YES} { count(); yylval.intval=1;
>>yy_number_str=yytext; return NUMBER; }
>> {NO} { count(); yylval.intval=0;
>>yy_number_str=yytext; return NUMBER; }
>>
>> In the devel version (upcoming 5.7.0), the evaluation of return mode can
>> be controlled by core parameter return_mode, allowing to switch to a more
>> "standard" mode, similar to other scripting languages -- see:
>>
>> - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
>>
>> Cheers,
>> Daniel
>>
>> On 28.04.23 08:14, Patrick Wakano wrote:
>>
>> Hi list,
>> Hope you are all well!
>>
>> I'm using Kamailio version 5.6.4 (installed from the repo
>> rpm.kamailio.org/centos/7) and noticed that every route that uses
>> "return false" is exiting the script, instead of returning This was not
>> the case on version 5.4.6 as the same script is running fine.
>> From this page
>> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
>> I would think that when a route returns false, it would return -1 and not
>> stop execution, since negative is equal to false, but it is actually
>> stopping (same as return 0)...
>> So, as an example, this test code doesn't work as expected. In case the
>> source is a public IP
[SR-Users] Re: Clarification of 'return false' behaviour
Thanks very much for the clarification Daniel! Appreciate it!
However it does seem that some modules have inconsistencies with return
values now. So, for instance, the is_ip_rfc918() says it will return true
or false (
https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
- most functions of this module return true or false) and then when used
directly with return, it terminates execution. Based on your explanation,
it shouldn't return true or false, but likely -1 or 1, which would never be
considered 'return 0'
Also, the below code works in version 5.4, but terminates execution in
version 5.6, so are you aware of changes in this behaviour in version 5.5
or 5.6 (before the 5.7 changes you mentioned)?
route[is_src_private]
{
return is_ip_rfc1918("$si");
}
request_route
{
...
if (route(is_src_private)) {
xlog("L_NOTICE", "SRC private\n");
} else {
xlog("L_NOTICE", "SRC public\n");
}
...
}
Best regards!
Patrick
On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
wrote:
> Hello,
>
> false is 0 and it was actually designed for setting global parameters, not
> for use as comparison with functions return code or as parameter for return
> from route blocks. Like:
>
> log_stderror = false
>
> The grammar of the language defines a coupe of token variants for same
> purpose:
>
>
>YES "yes"|"true"|"on"|"enable"
>NO "no"|"false"|"off"|"disable"
>
> Where YES is replaced by 1 and NO is replaced by 0:
>
>{YES} { count(); yylval.intval=1;
>yy_number_str=yytext; return NUMBER; }
>{NO} { count(); yylval.intval=0;
>yy_number_str=yytext; return NUMBER; }
>
> In the devel version (upcoming 5.7.0), the evaluation of return mode can
> be controlled by core parameter return_mode, allowing to switch to a more
> "standard" mode, similar to other scripting languages -- see:
>
> - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
>
> Cheers,
> Daniel
>
> On 28.04.23 08:14, Patrick Wakano wrote:
>
> Hi list,
> Hope you are all well!
>
> I'm using Kamailio version 5.6.4 (installed from the repo
> rpm.kamailio.org/centos/7) and noticed that every route that uses "return
> false" is exiting the script, instead of returning This was not the
> case on version 5.4.6 as the same script is running fine.
> From this page
> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
> I would think that when a route returns false, it would return -1 and not
> stop execution, since negative is equal to false, but it is actually
> stopping (same as return 0)...
> So, as an example, this test code doesn't work as expected. In case the
> source is a public IP, the script doesn't print the "SRC public" it just
> exits and then of course every other logic meant to be done is not
> executed
>
> route[is_src_private]
> {
> if (is_ip_rfc1918("$si")) {
> return true;
> }
> return false;
> #return is_ip_rfc1918("$si"); *# this doesn't work too in case
> the $si is a public IP*
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
> If is_src_private is changed to return -1 instead of false, then it all
> works fine.
>
> Also, I noticed that the following code will print "TEST: 0" in case the
> $si is public and then stop execution. So looks like false is really being
> converted to 0, but I guess that's unexpected... anyway apologies if I'm
> missing something obvious
> route[is_src_private]
> {
> $var(t) = false;
> if (is_ip_rfc1918("$si")) {
> $var(t) = true;
> }
> xlog("L_ERR", "TEST: $var(t)\n");
> return $var(t);
> }
>
> I could not find a recent ticket or email related to this situation and
> I've already spent hours trying to understand what is the logic/problem
> here, so would anyone have been across a similar case that could provide
> some insight and clarify what is the expected behaviour of the *false*
> usage (and boolean in general if possible)?
>
> Thank you,
> Kind regards,
> Patrick Wakano
>
> __
&
[SR-Users] Clarification of 'return false' behaviour
Hi list,
Hope you are all well!
I'm using Kamailio version 5.6.4 (installed from the repo
rpm.kamailio.org/centos/7) and noticed that every route that uses "return
false" is exiting the script, instead of returning This was not the
case on version 5.4.6 as the same script is running fine.
>From this page
https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
I would think that when a route returns false, it would return -1 and not
stop execution, since negative is equal to false, but it is actually
stopping (same as return 0)...
So, as an example, this test code doesn't work as expected. In case the
source is a public IP, the script doesn't print the "SRC public" it just
exits and then of course every other logic meant to be done is not
executed
route[is_src_private]
{
if (is_ip_rfc1918("$si")) {
return true;
}
return false;
#return is_ip_rfc1918("$si"); *# this doesn't work too in case the
$si is a public IP*
}
request_route
{
...
if (route(is_src_private)) {
xlog("L_NOTICE", "SRC private\n");
} else {
xlog("L_NOTICE", "SRC public\n");
}
...
}
If is_src_private is changed to return -1 instead of false, then it all
works fine.
Also, I noticed that the following code will print "TEST: 0" in case the
$si is public and then stop execution. So looks like false is really being
converted to 0, but I guess that's unexpected... anyway apologies if I'm
missing something obvious
route[is_src_private]
{
$var(t) = false;
if (is_ip_rfc1918("$si")) {
$var(t) = true;
}
xlog("L_ERR", "TEST: $var(t)\n");
return $var(t);
}
I could not find a recent ticket or email related to this situation and
I've already spent hours trying to understand what is the logic/problem
here, so would anyone have been across a similar case that could provide
some insight and clarify what is the expected behaviour of the *false*
usage (and boolean in general if possible)?
Thank you,
Kind regards,
Patrick Wakano
__
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] Centos kamailio.repo file is not updated
Hello ist, I've noticed some of the latest releases do not have their repo mentioned in the https://rpm.kamailio.org/centos/kamailio.repo The repos are there, it is just the kamailio.repo file missing some of the newer versions like 5.4.7, 4.5.8, 5.5.4, 5.6.0... Cheers, Patrick __ 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] Problem with auth_ephemeral and parse_uri(): bad port in uri
If auth_ephemeral gets deprecated, what would be a recommended approach to
replace it?
On Thu, 24 Feb 2022 at 21:46, Daniel-Constantin Mierla
wrote:
> Hello,
>
> it should be reviewed properly if does not work before removing. The
> entire auth_ephemeral is deprecated from specs point of view, as the
> ietf draft never made it to rfc, but it is still useful to use at least
> for PoC. I don't have access to some old deployments using mode 0 to see
> if they were changed meanwhile.
>
> Cheers,
> Daniel
>
> On 24.02.22 10:39, Henning Westerholt wrote:
> > Hello,
> >
> > yes, if it is not working and also deprecated, if probably should be
> removed. You could open an issue for that or create (even better) a pull
> request.
> >
> > Cheers,
> >
> > Henning
> >
> > --
> > Henning Westerholt – https://skalatan.de/blog/
> > Kamailio services – https://gilawa.com
> >
> > -Original Message-
> > From: sr-users On Behalf Of
> Vlasis Chatzistavrou
> > Sent: Sunday, February 20, 2022 8:07 PM
> > To: mico...@gmail.com; Kamailio (SER) - Users Mailing List <
> sr-users@lists.kamailio.org>
> > Subject: Re: [SR-Users] Problem with auth_ephemeral and parse_uri(): bad
> port in uri
> >
> > Hi Daniel,
> >
> > Just an update, I tested this with username_format set to 1 and set the
> > To: and From: headers to be the phone's username (ie without the
> timestamp). This worked without problems.
> >
> > However, setting the username_format to 0 (the deprecated option) does
> not work even with the correct To: and From: headers. Since this option is
> already deprecated perhaps it could be removed in future versions to avoid
> confusion?
> >
> > On 25/1/2022 11:38, Vlasis Chatzistavrou wrote:
> >> Thank you Daniel,
> >>
> >> I will give this a try.
> >>
> >> On 25/1/2022 11:11, Daniel-Constantin Mierla wrote:
> >>> Hello,
> >>>
> >>> as far as I remember, the format with "user:timestamp" is only for
> >>> authentication username field, respectively the username attribute in
> >>> Proxy-/Authorization header. The subscriber address is still
> >>> user@domain, so that has to be used in From/To headers.
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>> On 02.01.22 20:36, Vlasis Chatzistavrou wrote:
> Hello,
>
> I have a problem with Kamailio 5.4.6 and auth_ephemeral. I have the
> following in the Kamailio configuration
>
> loadmodule "auth_ephemeral"
> modparam( "auth_ephemeral", "sha_algorithm", 3 )
> modparam( "auth_ephemeral", "username_format", 0 )
> modparam( "auth_ephemeral", "secret", 1234 )
>
> as per
>
> https://kamailio.org/docs/modules/4.1.x/modules/auth_ephemeral.html#
> auth_eph.p.username_format
>
>
>
> and registrations fail. In the logs we see:
>
> Jan 2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545
> REGISTER rhaqgafd7boteg24jp5db0} sanity [sanity.c:777]:
> check_parse_uris(): looking up From header Jan 2 18:21:10
> enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER
> rhaqgafd7boteg24jp5db0} sanity [sanity.c:817]:
> check_parse_uris(): parsing From URI Jan 2 18:21:10 enswitch43
> /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER
> rhaqgafd7boteg24jp5db0}
> [core/parser/parse_uri.c:1296]: parse_uri(): bad port in uri (error
> at char 5 in state 2) parsed: (17)
> / (35) Jan 2 18:21:10
> enswitch43 /sbin/kamailio[37501]: WARNING: {1 545 REGISTER
> rhaqgafd7boteg24jp5db0} sanity [sanity.c:820]:
> check_parse_uris(): failed to parse From uri
>
>
> Apparently Kamailio is confused by the timestamp following the
> username separated by the : character. The REGISTER message is below:
>
> REGISTER sip:192.168.2.99 SIP/2.0
> Via: SIP/2.0/WSS 192.0.2.202;branch=z9hG4bK5452321
> Max-Forwards: 70
> To: "3518929"
> From: "3518929" ;tag=ht76o8b2b6
> Call-ID: phkj9mi2n3s3ju7uu3qq2f
> CSeq: 274 REGISTER
> Contact:
> ;reg-id=1;+sip.instance=" n:uuid:ca5e9372-dfa1-459a-b6ba-4398d23bd896>";expires=300
>
> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
> Supported: path, gruu, outbound
> User-Agent: Raspberry Phone (SipJS - 0.11.6)
> Content-Length: 0
>
> and Kamailio parses it as sip:: instead of
> sip::.
>
> Is this a bug that should be reported or is there any setting that I
> am missing?
>
>
> __
> 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
Re: [SR-Users] Best practice for Kamailio "cluster" front for many TLS connections
> > But, my main question is about the DMQ on two Kamailio nodes and what > happens in case one of them reloads. Are the dialogs and useloc synced > automatically on reload? Is there a template config to read about this? > Hi, unless there are new development on version 5.5 that I am not aware, on version 5.4, the dialogs do not sync automatically, so you need to save them on DB and read from DB on startup ( https://kamailio.org/docs/modules/5.4.x/modules/dialog.html#dialog.p.db_skip_load). The usrloc will sync without the need of a DB https://kamailio.org/docs/modules/5.4.x/modules/dmq_usrloc.html#usrloc_dmq.p.sync On Tue, 14 Sept 2021 at 22:44, Daniel-Constantin Mierla wrote: > Hello, > > for the records, there is a minimal config example in the repo: > > * > https://github.com/kamailio/kamailio/blob/master/misc/examples/mixed/kamailio-minimal-anycast.cfg > > Maybe it is useful for a starting point, although I think it targets use > of UDP. > > Cheers, > Daniel > On 13.09.21 08:46, Markus Monka wrote: > > Hi, > > we did some testing with ipvs but unfortunately where not been able to > pursue it further. > Today we use NAPTR/SRV Records for balancing to several TCP Loadbalancers. > > Best Regards > Markus > > On Mon, Sep 13, 2021 at 8:19 AM Henning Westerholt wrote: > >> Hello, >> >> >> >> I would suggest having a look at the presentation from Armen, and >> probably others from past KamailioWorld: >> >> >> >> https://www.youtube.com/c/KamailioWorld/search?query=anycast >> >> >> >> Cheers, >> >> >> >> Henning >> >> >> >> -- >> >> Henning Westerholt – https://skalatan.de/blog/ >> >> Kamailio services – https://gilawa.com >> >> >> >> *From:* sr-users *On Behalf Of *Angelo >> Sipper >> *Sent:* Sunday, September 12, 2021 11:44 AM >> *To:* Kamailio (SER) - Users Mailing List >> *Subject:* Re: [SR-Users] Best practice for Kamailio "cluster" front for >> many TLS connections >> >> >> >> Sorry Fred, >> >> >> >> I believe, my question was wrongly asked. >> >> The correct question would be, Is there a guide for Kamailio and Anycast >> that anyone could point me to read? >> >> >> >> But, my main question is about the DMQ on two Kamailio nodes and what >> happens in case one of them reloads. Are the dialogs and useloc synced >> automatically on reload? Is there a template config to read about this? >> >> >> >> Kind Regards, >> >> Angelo >> >> >> >> Στις Κυρ, 12 Σεπ 2021 στις 1:30 π.μ., ο/η Fred Posner >> έγραψε: >> >> To be clear here, this is the kamailio list and you’ve been referencing >> opensips documentation. >> >> -- Fred >> >> (via mobile) >> >> Matrix: @fred:matrix.lod.com >> >> >> >> >> >> On Sep 11, 2021, at 5:46 PM, Angelo Sipper wrote: >> >> >> >> HI, >> >> >> >> Thanks for all the suggestions. I will look into glb-director and I will >> come back in case I need more help. >> >> As I understand for same DC and two Kamailio's on active/standby with >> keepalived is fine, at least for the load we are expecting now. >> >> >> >> Now one question on DMQ. Up today with the one only Kamailio we are using >> the dialog db_mode 1 to have all dialogs in db, in order not to loose the >> dialogs in case of reload. When we will have 2 Kamailio's with DMQ sync for >> all dialogs, in case of one Kamailios reloads it will get all active >> dialogs from the other Kamailio without the need to have the DB to handle >> this and also delay the system. Is this the correct approach? >> >> >> >> Last, do you know any updated doc for Anycast - Kamailio like the one >> here for the older version 2.4 ? >> >> https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/ >> >> >> >> Kind Regards, >> >> Angelo >> >> >> >> >> >> Στις Σάβ, 11 Σεπ 2021 στις 11:03 μ.μ., ο/η Henning Westerholt < >> h...@skalatan.de> έγραψε: >> >> Hello Angelo, >> >> >> >> it is possible to use Kamailio with an anycast setup, there are two talks >> in the last years KamailioWorld conference about more details. >> >> >> >> But if we are only talking about several thousand clients, it’s not >> needed for a start. Its certainly possible to operate this just with one >> front-end Kamailio in an activate/passive setup, many people do this. >> >> E.g., look to this (rather old) performance tests, 1.000.000 contacts >> with TLS on one server >> http://sip-router.org/wiki/performance/v3.0-capacity >> >> >> >> Kamailio has no cluster module, you probably want to investigate the DMQ >> module which offers clustering capabilities. >> >> >> >> Cheers, >> >> >> >> Henning >> >> >> >> >> >> -- >> >> Henning Westerholt – https://skalatan.de/blog/ >> >> Kamailio services – https://gilawa.com >> >> >> >> *From:* sr-users *On Behalf Of *Angelo >> Sipper >> *Sent:* Saturday, September 11, 2021 8:52 PM >> *To:* Kamailio (SER) - Users Mailing List >> *Subject:* Re: [SR-Users] Best practice for Kamailio "cluster" front for >> many TLS connections >> >> >> >> Hi Fred, >> >> >> >> Thanks for the suggestions. >> >> I have been looking to all these
Re: [SR-Users] Manage multiple RTP streams with different TO-tags (forking)
I did have a very similar problem and it got solved by using the via-branch=auto in the rtpengine offer Check the comments here: https://github.com/sipwise/rtpengine/commit/23977237c0753c9877b082d71d45348387ad1606 On Fri, 27 Aug 2021 at 21:40, Julien Klingenmeyer < julien.klingenme...@ovhcloud.com> wrote: > Hi, > > > > I faced a quite same situation recently and I have asked on RTPEngine > Github: https://github.com/sipwise/rtpengine/issues/1330 > > Your scenario is a bit different but with the workaround described in the > issue (overriding to-tag flag in rtpengine request), maybe you can fix your > issue. > > > > Just also be careful when either Alice or Bob sends ReInvites within the > call, to-tag (or from-tag depending on who sent the request) will need to > be overridden too. > > > > Julien > > > > *De : *sr-users au nom de Arsen > Semenov > *Répondre à : *"Kamailio (SER) - Users Mailing List" < > sr-users@lists.kamailio.org> > *Date : *vendredi 27 août 2021 à 07:28 > *À : *"Kamailio (SER) - Users Mailing List" > *Objet : *Re: [SR-Users] Manage multiple RTP streams with different > TO-tags (forking) > > > > it's legal to get responses with different to-tags, since the request is > forked. this is what's happening in this scenario. > I think this is an issue of UAC/rtpengin how it is reacting to the second > SDP in 183 > > > > are the SDPs in 183 responses carried reliably? > > > > On Fri, Aug 27, 2021 at 2:51 PM Yuriy Gorlichenko > wrote: > > Hello. > > The first thing: to tag can't be changed due session once it passed. > > > > If provider uses forking mechanism the it has to be hidden from your > system. > > > > Regarding SDP according > > https://datatracker.ietf.org/doc/html/rfc3261#section-13.2.1 > > They can't change SDP answer description on the fly. Only first SDP answer > used as proper, all othe answers will be ignored. > > > > On Fri, 27 Aug 2021, 11:27 B. Tietz, wrote: > > Hello, > > > > following situation. > > I have a Kamailio (5.4) using rtpengine to loadbalance calls. > > > > If a call from Alice comes in, Kamailio decides to send the call to > Carrier B from Bob. > > Bobs Phone is ringing and the carrier B send a 183 Session Progress with > SDP and To-tag=abcd. The SDP has G722 as codec and port 1234. > > A few moments later carrier B send a second 183 Session Progress with SDP > and TO-tag=fghi. The SDP has G711 as codec and port 5678. This is done, to > play some funky music as ringtone -.- > > If Bob answers the call, carrier B sends a 200 OK WITHOUT SDP and > TO-tag=abcd. So this should instruct our Kamailio to switch to the first > G722 and port 1234. > > > > But sadly, this is just not working as expected. > > > > We tried to set the flags media-handover and port-latching for the > rtpengine options and additionally set a to-tag when using rtpenging_manage. > > But this doesn't solve the codec change, so we have only audio when Bob > answers the call, but no ringtone-music. If we allow G711 only in the > outgoing INVITE to Bob, we have also tha ringtone-muisic, because there is > no codec-change. > > > > Carrier B tells us, they are using a fork-mechanism. > > > > Is there something we can do, to support the codec change in 183? Or > enforce carrier B to send SDP in 200 OK? Or anything else? > > > > Carrier B can not change anything in the ringtone-music-backend. They are > stuck on G711. > > > > Thanks! > > __ > 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 > > > > > -- > > Arsen Semenov > > > __ > 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] Kamailio in VMware with Fault Tolerance on
Thanks for your input Sergio! Our current active-standby uses keepalived to manage the shared IP between the servers. It works fine. Now we are trying a new architecture as a step towards a public cloud deployment. On Tue, 3 Nov 2020, 21:45 Sergio Charrua, wrote: > Patrick, > > I would rely on Corosync and Pacemaker for failover, using a shared IP > address between (active + passive) servers. Once the active goes down, > Pacemaker switches the shared IP to the passive server that will then > become the active server. > > Hope this helps, > > *Sérgio Charrua* > > *www.voip.pt <http://www.voip.pt/>* > > Tel.: +351 21 130 71 77 > > Email : *sergio.char...@voip.pt * > > This message and any files or documents attached are strictly confidential > or otherwise legally protected. > > It is intended only for the individual or entity named. If you are not the > named addressee or have received this email in error, please inform the > sender immediately, delete it from your system and do not copy or disclose > it or its contents or use it for any purpose. Please also note that > transmission cannot be guaranteed to be secure or error-free. > > > > > > > > > On Tue, Nov 3, 2020 at 9:55 AM Daniel-Constantin Mierla > wrote: > >> Hello, >> >> is the active-active architecture still relying on a single shared ip >> that is migrated between the systems, or do you use two shared ips and each >> system is associated with one in normal operational mode? Or is anycast? >> >> Cheers, >> Daniel >> On 03.11.20 03:38, Patrick Wakano wrote: >> >> Thanks for the info Daniel! Much appreciated! >> Our previous architecture was active-standby with VIP and keepalived, >> however we are moving towards an active-active approach. >> Cheers, >> Patrick Wakano >> >> On Tue, 3 Nov 2020 at 04:40, Daniel-Constantin Mierla >> wrote: >> >>> Hello, >>> >>> I try to stay away from infrastructure, so I do not know the exact >>> technical details and whether it uses Fault Tolerance, but I have customers >>> using VMware, some with rather busy sip servers (5+ active users) and >>> all runs smooth there. But in this specific case, there is no DMQ, data is >>> shared via database (MySQL), the secondary system being in standby ready to >>> take over the IP of the primary server. >>> >>> Cheers, >>> Daniel >>> On 02.11.20 07:31, Patrick Wakano wrote: >>> >>> Hello list, >>> Hope you are all good! >>> >>> Recently, the issue https://github.com/kamailio/kamailio/issues/2535 >>> has been investigated and the utilization of the feature vsphere Fault >>> Tolerance is linked as a source of network latency and probably CPU >>> allocation latency. This increases the chances of the mentioned issue to >>> happen. >>> So I would just like to ask if anyone out there is using Kamilio in a >>> VMware environment with Fault Tolerance on? How is the experience? >>> >>> Kind regards, >>> Patrick Wakano >>> >>> ___ >>> 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 >>> >>> -- >> 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 >> > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio in VMware with Fault Tolerance on
Thanks for the info Daniel! Much appreciated! Our previous architecture was active-standby with VIP and keepalived, however we are moving towards an active-active approach. Cheers, Patrick Wakano On Tue, 3 Nov 2020 at 04:40, Daniel-Constantin Mierla wrote: > Hello, > > I try to stay away from infrastructure, so I do not know the exact > technical details and whether it uses Fault Tolerance, but I have customers > using VMware, some with rather busy sip servers (5+ active users) and > all runs smooth there. But in this specific case, there is no DMQ, data is > shared via database (MySQL), the secondary system being in standby ready to > take over the IP of the primary server. > > Cheers, > Daniel > On 02.11.20 07:31, Patrick Wakano wrote: > > Hello list, > Hope you are all good! > > Recently, the issue https://github.com/kamailio/kamailio/issues/2535 has > been investigated and the utilization of the feature vsphere Fault > Tolerance is linked as a source of network latency and probably CPU > allocation latency. This increases the chances of the mentioned issue to > happen. > So I would just like to ask if anyone out there is using Kamilio in a > VMware environment with Fault Tolerance on? How is the experience? > > Kind regards, > Patrick Wakano > > ___ > 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
[SR-Users] Kamailio in VMware with Fault Tolerance on
Hello list, Hope you are all good! Recently, the issue https://github.com/kamailio/kamailio/issues/2535 has been investigated and the utilization of the feature vsphere Fault Tolerance is linked as a source of network latency and probably CPU allocation latency. This increases the chances of the mentioned issue to happen. So I would just like to ask if anyone out there is using Kamilio in a VMware environment with Fault Tolerance on? How is the experience? Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio unresponsive with Dialog+DMQ
Hello, For reference, we updated Kamailio to version 5.4.2 and the problem still persists. So I opened the ticket ( https://github.com/kamailio/kamailio/issues/2535) to track the issue. Thank you, Patrick Wakano On Wed, 28 Oct 2020 at 10:38, Patrick Wakano wrote: > Hi Daniel! > Thanks for your reply! > I managed to get the kamctl trap output, it is attached here. This is a > case where Kamailio is unresponsive with the UDP workers stuck in the > mutex... > I agree with your observations, it goes along with what we were thinking... > > Kind regards, > Patrick Wakano > > On Tue, 27 Oct 2020 at 19:17, Daniel-Constantin Mierla > wrote: > >> The increase of memory is very likely the side effect of processes not >> handing the traffic, sip_msg_shm_clone() is manly used when creating the >> transactions. They can accumulate if the timer processes are stuck or other >> callback functions block the transactions hash table. As said in the other >> email, try to get the output of kamctl trap to have information about what >> all processes do at that moment. >> >> Cheers, >> Daniel >> >> ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio unresponsive with Dialog+DMQ
Hi Daniel! Thanks for your reply! I managed to get the kamctl trap output, it is attached here. This is a case where Kamailio is unresponsive with the UDP workers stuck in the mutex... I agree with your observations, it goes along with what we were thinking... Kind regards, Patrick Wakano On Tue, 27 Oct 2020 at 19:17, Daniel-Constantin Mierla wrote: > The increase of memory is very likely the side effect of processes not > handing the traffic, sip_msg_shm_clone() is manly used when creating the > transactions. They can accumulate if the timer processes are stuck or other > callback functions block the transactions hash table. As said in the other > email, try to get the output of kamctl trap to have information about what > all processes do at that moment. > > Cheers, > Daniel > > <> ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio unresponsive with Dialog+DMQ
Sorry to bother again, but another problem we are facing and that now seems
related is an increasing memory usage similar to a memory leak.
So during the load test, Kamailio shmem starts increasing fast making it
run out of shmem. Today it happened again and I could retrieve some info
and looks like the "leak" is likely due to the DMQ workers. The kamcmd
shmem stats showed high usage in core and dmq:
# kamcmd mod.stats all shm
Module: core
{
sip_msg_shm_clone(496): 959632704
counters_prefork_init(207): 61440
cfg_clone_str(130): 392
cfg_shmize(217): 1496
main_loop(1295): 8
init_pt(113): 8
init_pt(108): 8
init_pt(107): 5920
cfg_parse_str(906): 80
register_timer(1012): 432
cfg_register_ctx(47): 96
init_tcp(4714): 8192
init_tcp(4708): 32768
init_tcp(4700): 8
init_tcp(4693): 8
init_tcp(4686): 8
init_tcp(4680): 8
init_tcp(4668): 8
init_avps(90): 8
init_avps(89): 8
init_dst_blacklist(437): 16384
init_dst_blacklist(430): 8
timer_alloc(515): 96
init_dns_cache(358): 8
init_dns_cache(350): 16384
init_dns_cache(343): 16
init_dns_cache(336): 8
init_timer(284): 8
init_timer(283): 16384
init_timer(282): 8
init_timer(281): 8
init_timer(270): 8
init_timer(238): 8
init_timer(221): 278544
init_timer(220): 8
init_timer(207): 8
cfg_child_cb_new(828): 64
sr_cfg_init(360): 8
sr_cfg_init(353): 8
sr_cfg_init(346): 8
sr_cfg_init(334): 8
sr_cfg_init(322): 8
qm_shm_lock_init(1202): 8
Total: 960071600
}
Module: dmq
{
alloc_job_queue(250): 64
shm_str_dup(723): 48
build_dmq_node(164): 896
add_peer(68): 312
mod_init(240): 8
mod_init(233): 48
init_dmq_node_list(70): 24
init_peer_list(33): 24
job_queue_push(286): 15369848
Total: 15371272
}
>From GDB I could see both workers were stuck here:
Thread 1 (Thread 0x7f4a3cba7740 (LWP 17401)):
#0 0x7f4a3c29dbf9 in syscall () from /lib64/libc.so.6
#1 0x7f49f1a44bdd in futex_get (lock=0x7fff1d14f564) at
../../core/futexlock.h:121
#2 0x7f49f1a4fe57 in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657
mypid = 17401
index = 2543
entry = {first = 0x0, last = 0x0, next_id = 107271, lock = {val =
2}, locker_pid = {val = 17393}, rec_lock_level = 0}
dlg = 0x0
__FUNCTION__ = "dmq_send_all_dlgs"
#3 0x7f49f1a4c000 in dlg_dmq_handle_msg (msg=0x7f49fe88b2b8,
resp=0x7fff1d14f8e0, node=0x7f49fd4be5d8) at dlg_dmq.c:391
#4 0x7f49f25da34a in worker_loop (id=1) at worker.c:113
#5 0x7f49f25d7d35 in child_init (rank=0) at dmq.c:300
Thread 1 (Thread 0x7f4a3cba7740 (LWP 17400)):
#0 0x7f4a3c29dbf9 in syscall () from /lib64/libc.so.6
#1 0x7f49f1a44bdd in futex_get (lock=0x7fff1d14f564) at
../../core/futexlock.h:121
#2 0x7f49f1a4fe57 in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657
mypid = 17400
index = 1080
entry = {first = 0x7f49fe575ad0, last = 0x7f49fe575ad0, next_id =
54971, lock = {val = 2}, locker_pid = {val = 17385}, rec_lock_level = 0}
dlg = 0x0
__FUNCTION__ = "dmq_send_all_dlgs"
#3 0x7f49f1a4c000 in dlg_dmq_handle_msg (msg=0x7f49fe437878,
resp=0x7fff1d14f8e0, node=0x7f49fd4be5d8) at dlg_dmq.c:391
#4 0x7f49f25da34a in worker_loop (id=0) at worker.c:113
#5 0x7f49f25d7d35 in child_init (rank=0) at dmq.c:300
>From my analysis, it seems memory was increasing because every new call was
adding a new job to the dmq workers queue but the workers were stuck in the
mutex not consuming the jobs. We could not figure out which process had the
mutex, because from GDB the locker_pid had an UDP process and a timer
process, but both seemed to be just waiting in normal operation.
Also, I didn't create a ticket because 5.2 is deprecated, but I found it
worth reporting this potential problem in the list since it looks like the
code for the DMQ is similar between 5.4 and 5.2.
On Tue, 27 Oct 2020 at 09:22, Patrick Wakano wrote:
> Hello list,
> Hope all are doing well!
>
> We are running load tests in our Kamailio server, that is just making
> inbound and outbound calls and eventually (there is no identified pattern)
> Kamailio freezes and of course all calls start to fail. It does not crash,
> it just stops responding and it has to be killed -9. When this happens, SIP
> messages are not processed, dmq keepalive fails (so the other node reports
> as down), dialog KA are not sent, but Registrations from UAC seem to still
> go out (logs from local_route are seen).
> We don't have a high amount of cps, it is max 3 or 4 per sec, and it gets
> around 1900 active calls. We are now using Kamailio 5.2.8 installed from
> the repo on a CentOS7 server. Dialog has KA active and DMQ (with 2 workers)
> is being used on an active-active instance.
> From investigation using GDB as pasted below, I can see UDP workers are
> stuck on a lock either on a callback from t_relay...
> #0 0x7ffb74e9bbf9 in syscall () from /lib64/libc.so.6
> #1 0x7ffb2b1bce08 in futex_get (lock=0x7ffb35217b90) at
> ../../cor
[SR-Users] Kamailio unresponsive with Dialog+DMQ
msg=0x7ffb742f1930, param_branch=0x7fff2e963ebc) at t_lookup.c:1101 #9 0x7ffb2eee44c7 in t_check_trans (msg=0x7ffb742f1930) at tm.c:2351 And the DMQ workers are here: #0 0x7ffb74e9bbf9 in syscall () from /lib64/libc.so.6 #1 0x7ffb2b1d6c81 in futex_get (lock=0x7ffb35217c34) at ../../core/futexlock.h:108 #2 0x7ffb2b1d7c3a in worker_loop (id=1) at worker.c:86 #3 0x7ffb2b1d5d35 in child_init (rank=0) at dmq.c:300 Currently I will not be able to upgrade to latest 5.4 version to try to reproduce the error and since 5.2.8 has already reached end-of-life, maybe is there anything I can do on the configuration to avoid such condition? Any ideas are welcome! Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Handling of packet loss in the Kamailio to RTPEngine control protocol
Thanks for the explanation Richard! Much appreciated! Sorry I didn't read the documentation properly I agree the network should be more reliable, but I will investigate if those parameters can help me. That's good news about the HTTP and websocket support! Looking forward to it! Thank you! Kind regards! On Thu, 3 Sep 2020 at 22:34, Richard Fuchs wrote: > On 02/09/2020 19.30, Patrick Wakano wrote: > > Hello list, > Hope you are all well. > > Under some load test simulations I've been facing cases where the command > Kamailio sends to RTPEngine times out with such message: > send_rtpp_command(): timeout waiting reply for command "" from RTP proxy > After checking RTPEngine logs, I can see the command was received and a > reply was sent, so I am thinking the reply packet could have been lost > somewhere in the network (they are in different servers). So my question > is, how resilient is the RTPEngine NG protocol to handle packet loss > situations? I saw TCP is not supported, so are there UDP retransmissions in > place to guarantee packet delivery? Any ideas to make this connection more > reliable? > > The module automatically resends the command a number of times if no reply > was received within the timeout period. The modparam `rtpengine_retr` is > how many times a command is resent, and `rtpengine_tout_ms` is how long it > waits (in ms) each time for a reply. > > If you don't get a reply even after multiple retries, you might have an > underlying network issue. Most often this is due to broken IP fragmentation > in the network. > > We're currently working on adding HTTP and Websocket support to rtpengine, > so this could be used in the future as control protocol from Kamailio > instead of UDP, even though in a properly functioning network there's no > reason why UDP shouldn't be as reliable as TCP. > > 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
[SR-Users] Handling of packet loss in the Kamailio to RTPEngine control protocol
Hello list, Hope you are all well. Under some load test simulations I've been facing cases where the command Kamailio sends to RTPEngine times out with such message: send_rtpp_command(): timeout waiting reply for command "" from RTP proxy After checking RTPEngine logs, I can see the command was received and a reply was sent, so I am thinking the reply packet could have been lost somewhere in the network (they are in different servers). So my question is, how resilient is the RTPEngine NG protocol to handle packet loss situations? I saw TCP is not supported, so are there UDP retransmissions in place to guarantee packet delivery? Any ideas to make this connection more reliable? Kind regards, Thank you, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio CentOS 7 repos broken
Hi list, Hope you are all good! I've been trying to install kamailio 5.2.7 from the centos 7 repo, but it is failing in both repos. With the http://rpm.kamailio.org/centos/ repo it fails with: Error: Package: kamailio-sipcapture-daemon-config-5.2.7-0.el7.centos.x86_64 (kamailio-5.2) Requires: kamailio-sipcapture = 5.2.7 With the http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentOS_7/ repo it fails with: kamailio-5.2.7-7.el7.centos.x8 FAILED ===] 579 kB/s | 12 MB 00:00:04 ETA https://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.2.x-rpms/CentOS_7/x86_64/kamailio-5.2.7-7.el7.centos.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=home_kamailio_v5.2.x-rpms clean metadata Trying other mirror. Error downloading packages: kamailio-5.2.7-7.el7.centos.x86_64: [Errno 256] No more mirrors to try. Would someone be able to have a look at that? Thank you! Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Drop local generated requests
Never mind Daniel, just saw this in the 5.4 release notes ( https://www.kamailio.org/wiki/features/new-in-5.4.x): tm - add support for dropping messages in local-request event route Thank you, On Fri, 10 Jul 2020 at 15:14, Patrick Wakano wrote: > Hi Daniel, > Sorry coming back to this, but I downloaded the 5.3.5 version and a drop() > from the tm:local-request doesn't work. Also changing $du does not affect > the message relay > Could you possibly check if the support you saw in master has indeed been > released? > > Thank you very much, > Patrick Wakano > > > On Wed, 8 Jul 2020 at 18:14, Patrick Wakano wrote: > >> Hi Daniel, >> I am still on 5.2. So maybe it's time to upgrade! >> Thanks for the reply! >> >> Cheers! >> Patrick >> >> On Wed, 8 Jul 2020, 17:37 Daniel-Constantin Mierla, >> wrote: >> >>> Hello, >>> >>> what is the kamailio version you use? The code master branch indicates >>> that it should support handling the use of drop in event route for local >>> requests. >>> >>> Cheers, >>> Daniel >>> On 08.07.20 09:33, Patrick Wakano wrote: >>> >>> Hello list, >>> Hope you all doing fine! >>> >>> I have a case where I want to drop a local generated request but it >>> looks like you can't drop the request from the tm:local-request route. I >>> found this ticket https://github.com/kamailio/kamailio/issues/980, but >>> I could not find somewhere in the docs or emails definitely saying that >>> drop() is not supported from tm:local-request >>> And in case we definitely can't drop the request in there, any ideas on >>> how to avoid a local generated request of going out? I am specifically >>> interested in dropping Registers from the uacreg module under certain >>> situations, but I don't want to disable it or delete it from the DB >>> >>> Thank you, >>> Kind regards, >>> Patrick Wakano >>> >>> ___ >>> 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] Drop local generated requests
Hi Daniel, Sorry coming back to this, but I downloaded the 5.3.5 version and a drop() from the tm:local-request doesn't work. Also changing $du does not affect the message relay Could you possibly check if the support you saw in master has indeed been released? Thank you very much, Patrick Wakano On Wed, 8 Jul 2020 at 18:14, Patrick Wakano wrote: > Hi Daniel, > I am still on 5.2. So maybe it's time to upgrade! > Thanks for the reply! > > Cheers! > Patrick > > On Wed, 8 Jul 2020, 17:37 Daniel-Constantin Mierla, > wrote: > >> Hello, >> >> what is the kamailio version you use? The code master branch indicates >> that it should support handling the use of drop in event route for local >> requests. >> >> Cheers, >> Daniel >> On 08.07.20 09:33, Patrick Wakano wrote: >> >> Hello list, >> Hope you all doing fine! >> >> I have a case where I want to drop a local generated request but it looks >> like you can't drop the request from the tm:local-request route. I found >> this ticket https://github.com/kamailio/kamailio/issues/980, but I could >> not find somewhere in the docs or emails definitely saying that drop() is >> not supported from tm:local-request >> And in case we definitely can't drop the request in there, any ideas on >> how to avoid a local generated request of going out? I am specifically >> interested in dropping Registers from the uacreg module under certain >> situations, but I don't want to disable it or delete it from the DB >> >> Thank you, >> Kind regards, >> Patrick Wakano >> >> ___ >> 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] Drop local generated requests
Hi Daniel, I am still on 5.2. So maybe it's time to upgrade! Thanks for the reply! Cheers! Patrick On Wed, 8 Jul 2020, 17:37 Daniel-Constantin Mierla, wrote: > Hello, > > what is the kamailio version you use? The code master branch indicates > that it should support handling the use of drop in event route for local > requests. > > Cheers, > Daniel > On 08.07.20 09:33, Patrick Wakano wrote: > > Hello list, > Hope you all doing fine! > > I have a case where I want to drop a local generated request but it looks > like you can't drop the request from the tm:local-request route. I found > this ticket https://github.com/kamailio/kamailio/issues/980, but I could > not find somewhere in the docs or emails definitely saying that drop() is > not supported from tm:local-request > And in case we definitely can't drop the request in there, any ideas on > how to avoid a local generated request of going out? I am specifically > interested in dropping Registers from the uacreg module under certain > situations, but I don't want to disable it or delete it from the DB > > Thank you, > Kind regards, > Patrick Wakano > > ___ > 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
[SR-Users] Drop local generated requests
Hello list, Hope you all doing fine! I have a case where I want to drop a local generated request but it looks like you can't drop the request from the tm:local-request route. I found this ticket https://github.com/kamailio/kamailio/issues/980, but I could not find somewhere in the docs or emails definitely saying that drop() is not supported from tm:local-request And in case we definitely can't drop the request in there, any ideas on how to avoid a local generated request of going out? I am specifically interested in dropping Registers from the uacreg module under certain situations, but I don't want to disable it or delete it from the DB Thank you, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpengine with mutiple IPs on the same network.
Check your output to the command "ip route show table local". For a connected network, the kernel will select the source IP based on these rules. From memory I think, it is possible to change the "src" parameter to use a different IP, so you can play with that. Anyway, as a general rule, I don't think having multiple IP addresses on the same subnet is a good practice. I would recommend breaking that into multiple subnets so you won't fall under these edge cases. Cheers, Patrick On Sun, 5 Jul 2020 at 15:33, Sergey Safarov wrote: > you can also look > > https://www.usenix.org/system/files/login/articles/login_summer16_10_anderson.pdf > > On Sun, Jul 5, 2020 at 8:02 AM Sergey Safarov wrote: > >> Required configure police based routing >> >> https://www.drdobbs.com/policy-routing-in-linux/199100936 >> >> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-policy-based-routing-to-define-alternative-routes_configuring-and-managing-networking >> >> >> On Sun, Jul 5, 2020 at 2:54 AM David Villasmil < >> david.villasmil.w...@gmail.com> wrote: >> >>> I know this is more of a networking routing question, just trying to see >>> if you can find a better solution than re-architecturing the network. >>> Although maybe that’s the best approach, since this is a pretty new setup. >>> Maybe it’s better to do it now and not using work-arounds? >>> >>> On Sun, 5 Jul 2020 at 00:39, David Villasmil < >>> david.villasmil.w...@gmail.com> wrote: >>> Hello guys, I have rtpengine running on a box with ips like this: external: 172.10.0.10 (advertise 10.10.10.1) internal: 172.10.0.11 Both Ips are on the same network. When i do rtpengine_manage i set "direction=external direction=internal", and the SDP offer is correct. The problem I'm having is that when rtp tried to send to the internal network, the OS (i believe) selects the first interface (external) ip 172.10.0.10 to reach the internal network. This I suppose is not a great deal, but I would like to separate them and only use the internal for internal proxying. Help is appreciated! Thanks! Regards, David Villasmil email: david.villasmil.w...@gmail.com phone: +34669448337 >>> -- >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.w...@gmail.com >>> phone: +34669448337 >>> ___ >>> 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] set_advertised_address not accepting vars
There is an open ticket for that:
https://github.com/kamailio/kamailio/issues/2137
On Mon, 23 Mar 2020 at 03:20, Sergiu Pojoga wrote:
> Thanks Daniel, I'll give it a try using xavps instead.
>
> Regards,
> --Sergiu
>
> On Sun, Mar 22, 2020 at 9:52 AM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> there is an alternative where you can use a combination of xavps and
>> corex module function via_use_xavp_fields() -- see:
>>
>> * https://www.kamailio.org/wiki/cookbooks/5.3.x/core#xavp_via_fields
>>
>> I think I looked at some point at set_advertised_address() from core to
>> make it accept variables, but its current form does some pre-compilation at
>> startup, keeping back references that are used at runtime, so it was not an
>> easy update. But we can add new functions to set those xavps and the
>> internal flag, if people find it simpler. The old function can stay for
>> those that want to work with static values for a bit of more speed.
>>
>> Cheers,
>> Daniel
>>
>> On 22.03.20 14:07, Sergiu Pojoga wrote:
>>
>> Hi there,
>>
>> The function doesn't appear to accept vars.
>>
>> For example, set_advertised_address("$var(someaddress)") results in a VIA
>> of string $var(someaddress), instead of var's value.
>>
>> https://www.kamailio.org/wiki/cookbooks/5.3.x/core#set_advertised_address
>>
>> kamailio 5.3.2 (x86_64/linux) 0bed10
>>
>> Cheers.
>> --Sergiu
>>
>> ___
>> 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] Ideas to reject a call due to RTPEngine failure when handling the 200Ok
I know that, and if that happens for the initial INIVITE I can properly fail the call with a 50X. However when I am already dealing with the 200Ok, the options are very limited and it is not clear to me what is the correct approach On Fri, 24 Jan 2020 at 09:16, Alex Balashov wrote: > If the RTPEngine fails to answer the offer or answer command, the SDP > will be left unmodified. > > But of course, that will not result in a proper media path. > > On Fri, Jan 24, 2020 at 09:01:25AM +1100, Patrick Wakano wrote: > > > Hello list, > > Hope you all doing well! > > > > I have a setup of Kamailio + RTPEngine (so no B2BUA), and I've come to a > > situation which I can't really figure out the best decision. > > The case is a late SDP negotiation that the 200Ok with the SDP offer > fails > > to engage the RTPEngine (for example no RTPEngine available). Also, the > > same problem can happen with a normal SDP negotiation, in case the INVITE > > goes through normally but then when engaging the SDP answer for the > 200Ok, > > the RTPengine answer request fails for any reason... > > In these cases, I can't generate a proper SDP for the 200OOk so the call > > will connect normally, but the media path will be broken... > > So for such cases, I am thinking it is reasonable to fail the call. > > However, failing a call during the 200Ok stage is tricky, at this point > we > > can't convert the 200Ok to a 50X. I tried and Kamailio doesn't allow and > > also RFC wise this is a no no for a SIP proxy > > I could completely remove the SDP body and forward the 200Ok. This will > > force a failed SDP negotiation and leave it for the endpoints the task to > > terminate the call. Is that acceptable? Has anyone faced such situation? > > Any idea is much appreciated! > > > > Kind regards, > > Patrick Wakano > > > ___ > > 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] Ideas to reject a call due to RTPEngine failure when handling the 200Ok
Hello list, Hope you all doing well! I have a setup of Kamailio + RTPEngine (so no B2BUA), and I've come to a situation which I can't really figure out the best decision. The case is a late SDP negotiation that the 200Ok with the SDP offer fails to engage the RTPEngine (for example no RTPEngine available). Also, the same problem can happen with a normal SDP negotiation, in case the INVITE goes through normally but then when engaging the SDP answer for the 200Ok, the RTPengine answer request fails for any reason... In these cases, I can't generate a proper SDP for the 200OOk so the call will connect normally, but the media path will be broken... So for such cases, I am thinking it is reasonable to fail the call. However, failing a call during the 200Ok stage is tricky, at this point we can't convert the 200Ok to a 50X. I tried and Kamailio doesn't allow and also RFC wise this is a no no for a SIP proxy I could completely remove the SDP body and forward the 200Ok. This will force a failed SDP negotiation and leave it for the endpoints the task to terminate the call. Is that acceptable? Has anyone faced such situation? Any idea is much appreciated! Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TLS testing (with sipp)
You just need to inform the certificate and key. It is informed in the docs (http://sipp.sourceforge.net/doc/reference.html#TLS+mono+socket) Use sipp options: t -l1 -tls_cert user-cert.pem -tls_key user-privkey.pem On Thu, 19 Dec 2019 at 03:33, Sebastian Damm wrote: > Hi, > > I'm trying to construct an end-to-end encrypted signalling test > through our setup. I thought I could use sipp for that, as it supports > TLS according to the man page. However, when I try to run it, I get > this error: > > FI_init_ssl_context: SSL_CTX_use_certificate_file failed. > > I searched the web; however, all similar questions end up without > answers. I tried specifying a local key and cert without success. I'd > think I should not need a cert for my client, though. > > Has anyone ever successfully conducted an automated TLS test? I'm open > to using a different tool if necessary. > > Thanks for all hints or examples. > > Regards, > 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] Possible conflict between t_newtran and setflag for ACC
Much appreciated Henning! It will be really helpful! Thank you, Patrick Wakano On Sat, 30 Nov 2019 at 05:41, Henning Westerholt wrote: > Hello, > > > > a note has been added. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > *From:* sr-users *On Behalf Of *Patrick > Wakano > *Sent:* Thursday, November 28, 2019 11:14 PM > *To:* Andrew Pogrebennyk > *Cc:* Kamailio (SER) - Users Mailing List > *Subject:* Re: [SR-Users] Possible conflict between t_newtran and setflag > for ACC > > > > Thanks Andrew! > > Daniel also pointed me out to this function. > > I just think it is probably needed to add a note in the t_newtran docs > that flags will be lost and the t_flush_flags should be used and not the > other way around as it is today, specially because one function is in the > TM module and the other in the TMX > > > > Kind regards, > > Patrick Wakano > > > > On Fri, 29 Nov 2019 at 01:08, Andrew Pogrebennyk > wrote: > > On 11/27/19 3:26 AM, Patrick Wakano wrote: > > I am using the ACC module and using the setflag() function as done in > > several examples. It works fine. However, I've added the t_newtran() > > function almost in the begging of the INVITE handler to help the > > retransmission detection and after that I noticed the ACC was not > > saving anything in DB. > > So after debugging I discovered that if I call the t_newtran() before > > setting the ACC flags, the module will not save the calls in DB, but > > if I call it after setting the ACC flags, it works > > So my question is, is this a bug or it is a expected side effect so > > when one is using t_newtran you must be careful and set all your > > transaction flags before? (ACC are the only transaction flags I am > > using so can't tell if other modules have the same problem) > > This is happening in Kamailio 5.2.2. > > Hi Patrick, > > just wanted to point out there is a function t_flush_flags, and it did > the trick for me when I observed the same as you a couple of > versions/years ago: > > http://www.kamailio.org/docs/modules/5.1.x/modules/tmx.html#tmx.f.t_flush_flags > > Regards, > > Andrew > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible conflict between t_newtran and setflag for ACC
Thanks Andrew! Daniel also pointed me out to this function. I just think it is probably needed to add a note in the t_newtran docs that flags will be lost and the t_flush_flags should be used and not the other way around as it is today, specially because one function is in the TM module and the other in the TMX Kind regards, Patrick Wakano On Fri, 29 Nov 2019 at 01:08, Andrew Pogrebennyk wrote: > On 11/27/19 3:26 AM, Patrick Wakano wrote: > > I am using the ACC module and using the setflag() function as done in > > several examples. It works fine. However, I've added the t_newtran() > > function almost in the begging of the INVITE handler to help the > > retransmission detection and after that I noticed the ACC was not > > saving anything in DB. > > So after debugging I discovered that if I call the t_newtran() before > > setting the ACC flags, the module will not save the calls in DB, but > > if I call it after setting the ACC flags, it works > > So my question is, is this a bug or it is a expected side effect so > > when one is using t_newtran you must be careful and set all your > > transaction flags before? (ACC are the only transaction flags I am > > using so can't tell if other modules have the same problem) > > This is happening in Kamailio 5.2.2. > > Hi Patrick, > > just wanted to point out there is a function t_flush_flags, and it did > the trick for me when I observed the same as you a couple of > versions/years ago: > > http://www.kamailio.org/docs/modules/5.1.x/modules/tmx.html#tmx.f.t_flush_flags > > Regards, > > Andrew > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible conflict between t_newtran and setflag for ACC
Thanks for your reply Henning! I also removed it from my script. The only thing is that when using it there is this nasty side effect, so I think if the function is meaningless it can be removed. I will create a ticket for it, so it can be evaluated what is the best approach. Thank you, Kind regards, Patrick Wakano On Thu, 28 Nov 2019 at 06:12, Henning Westerholt wrote: > Hello, > > > > usually it is not needed anymore to do this t_newtran early in the cfg. > Check this discussion from 2015 out: > > > > > http://sip-router.1086192.n5.nabble.com/Transaction-good-practices-with-t-relay-t-newtran-and-t-release-td137433.html > > > > There is also another function in tmx, t_precheck_trans which can be used > to detect re-transmissions without actually creating a new one. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > *From:* sr-users *On Behalf Of *Patrick > Wakano > *Sent:* Wednesday, November 27, 2019 3:26 AM > *To:* Kamailio (SER) - Users Mailing List > *Subject:* [SR-Users] Possible conflict between t_newtran and setflag for > ACC > > > > Hello list, > > Hope you all doing well! > > > > I am using the ACC module and using the setflag() function as done in > several examples. It works fine. However, I've added the t_newtran() > function almost in the begging of the INVITE handler to help the > retransmission detection and after that I noticed the ACC was not saving > anything in DB. > > So after debugging I discovered that if I call the t_newtran() before > setting the ACC flags, the module will not save the calls in DB, but if I > call it after setting the ACC flags, it works > > So my question is, is this a bug or it is a expected side effect so when > one is using t_newtran you must be careful and set all your transaction > flags before? (ACC are the only transaction flags I am using so can't tell > if other modules have the same problem) > > This is happening in Kamailio 5.2.2. > > > > Thank you! > > Kind regards, > > Patrick Wakano > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Possible conflict between t_newtran and setflag for ACC
Hello list, Hope you all doing well! I am using the ACC module and using the setflag() function as done in several examples. It works fine. However, I've added the t_newtran() function almost in the begging of the INVITE handler to help the retransmission detection and after that I noticed the ACC was not saving anything in DB. So after debugging I discovered that if I call the t_newtran() before setting the ACC flags, the module will not save the calls in DB, but if I call it after setting the ACC flags, it works So my question is, is this a bug or it is a expected side effect so when one is using t_newtran you must be careful and set all your transaction flags before? (ACC are the only transaction flags I am using so can't tell if other modules have the same problem) This is happening in Kamailio 5.2.2. Thank you! Kind regards, Patrick Wakano ___ 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 retrieve local socket that will be used to send a message from the branch route
Just rectifying about the $snd variable. While the wiki tells that $snd == $sndfrom, I discovered that the $snd == $sndto. So in my case, the $sndfrom(ip) gives me the local socket the message is being sent. However this only works from the onsend_route. I wasn't using this route at all, so now I need to check whether a call to rtpengine_offer will properly work from it. On Fri, 22 Nov 2019 at 10:01, Patrick Wakano wrote: > Yes David, we have all sorts of weird things (specially legacy > installations where creativity really shined). Also, in some private > network architectures my external interface may not have a public IP at > all > Anyway, I first thought about applying some logic on the destination IP, > but it is only reliable if I know my routing table, and this task Kamailio > already performs when relaying The easiest way for now seems to save > the info in the DB, so I explicit tell from which socket each GW is > reachable > > And for curiosity I attempted the $snd() variables but they don't have the > socket information the $snd(ip) has the destination IP, not my local > socket as the doc may suggest.The $branch variable ( > http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#branch_name_-_branch_attributes) > was promising but I couldn't figure out when it is set. In my branch_routes > it is always null.. > > > On Fri, 22 Nov 2019 at 09:15, David Villasmil < > david.villasmil.w...@gmail.com> wrote: > >> Hello, >> >> Interesting challenge you’ve got. >> >> It may fail in cases where my kernel routing table has some rule where a >> private IP is reachable via my external interface but different GW for >> example >> >> In this case then, the $du will be a rfc1918 ip but the outgoing >> interface will be a public ip? >> >> Have you tried $send(name) ? >> >> The docs state: >> >> Send Address Attributes >> $sndfrom(name) >> >> *$snd(name)* - return attributes of the address from where the request >> is going to be sent (local socket). >> >> On Thu, 21 Nov 2019 at 22:57, Patrick Wakano wrote: >> >>> Thanks for the replies and examples! Much appreciated! >>> >>> I was thinking of something similar to David suggestion, but I think >>> this is not 100% reliable. It may fail in cases where my kernel routing >>> table has some rule where a private IP is reachable via my external >>> interface but different GW for example (multiple IPs in the same interface >>> or more complex network architecture with VPN or direct link with some >>> endpoint) So given Kamailio already consults the kernel looking for the >>> correct interface to a given destination, I thought this is actually the >>> correct information I should use in my script. The only problem is that >>> apparently Kamailio is not exposing this info for the script writer >>> Karsten suggestion should probably work but in short this is just a way >>> to statically save in DB the network routing information I know before >>> hand. If this route changes (which should not happen often I agree) then I >>> have to update the DB. And also this DB data could be replaced by some >>> logic in my script if I had access to the chosen socket... That's exactly >>> the purpose of having mhomed=1 in the script, I don't need to save socket >>> info for all my GWs in DB because I am letting Kamailio automatically >>> decide it. And it does pretty well! The only problem now is that I don't >>> know what this decision was and I need it to implement the RTPEngine logic >>> in my script based on the interface the INVITE will go out. >>> >>> Happy to hear more ideas! >>> Thanks, >>> Kind regards, >>> Patrick Wakano >>> >>> On Thu, 21 Nov 2019 at 20:07, Karsten Horsmann >>> wrote: >>> >>>> Hi Patrick, >>>> >>>> If you don't use tls at this moment, the config from sbc OS is also an >>>> good example of using dispatcher with the socket params to select the right >>>> sendsock and using vars to give rtpengine the right internal / external >>>> directions. They use numbers for internal and external. To figure out where >>>> the direction is, this config use pseudo vars for receiving local socket >>>> >>>> >>>> https://github.com/voiceboys/sbcOS/blob/master/SbcOS/configs/voice/kamailio/kamailio.cfg#L450 >>>> >>>> Cheers >>>> Karsten Horsmann >>>> >>>> Patrick Wakano schrieb am D
Re: [SR-Users] How to retrieve local socket that will be used to send a message from the branch route
Yes David, we have all sorts of weird things (specially legacy installations where creativity really shined). Also, in some private network architectures my external interface may not have a public IP at all Anyway, I first thought about applying some logic on the destination IP, but it is only reliable if I know my routing table, and this task Kamailio already performs when relaying The easiest way for now seems to save the info in the DB, so I explicit tell from which socket each GW is reachable And for curiosity I attempted the $snd() variables but they don't have the socket information the $snd(ip) has the destination IP, not my local socket as the doc may suggest.The $branch variable ( http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#branch_name_-_branch_attributes) was promising but I couldn't figure out when it is set. In my branch_routes it is always null.. On Fri, 22 Nov 2019 at 09:15, David Villasmil < david.villasmil.w...@gmail.com> wrote: > Hello, > > Interesting challenge you’ve got. > > It may fail in cases where my kernel routing table has some rule where a > private IP is reachable via my external interface but different GW for > example > > In this case then, the $du will be a rfc1918 ip but the outgoing interface > will be a public ip? > > Have you tried $send(name) ? > > The docs state: > > Send Address Attributes > $sndfrom(name) > > *$snd(name)* - return attributes of the address from where the request is > going to be sent (local socket). > > On Thu, 21 Nov 2019 at 22:57, Patrick Wakano wrote: > >> Thanks for the replies and examples! Much appreciated! >> >> I was thinking of something similar to David suggestion, but I think this >> is not 100% reliable. It may fail in cases where my kernel routing table >> has some rule where a private IP is reachable via my external interface but >> different GW for example (multiple IPs in the same interface or more >> complex network architecture with VPN or direct link with some >> endpoint) So given Kamailio already consults the kernel looking for the >> correct interface to a given destination, I thought this is actually the >> correct information I should use in my script. The only problem is that >> apparently Kamailio is not exposing this info for the script writer >> Karsten suggestion should probably work but in short this is just a way >> to statically save in DB the network routing information I know before >> hand. If this route changes (which should not happen often I agree) then I >> have to update the DB. And also this DB data could be replaced by some >> logic in my script if I had access to the chosen socket... That's exactly >> the purpose of having mhomed=1 in the script, I don't need to save socket >> info for all my GWs in DB because I am letting Kamailio automatically >> decide it. And it does pretty well! The only problem now is that I don't >> know what this decision was and I need it to implement the RTPEngine logic >> in my script based on the interface the INVITE will go out. >> >> Happy to hear more ideas! >> Thanks, >> Kind regards, >> Patrick Wakano >> >> On Thu, 21 Nov 2019 at 20:07, Karsten Horsmann >> wrote: >> >>> Hi Patrick, >>> >>> If you don't use tls at this moment, the config from sbc OS is also an >>> good example of using dispatcher with the socket params to select the right >>> sendsock and using vars to give rtpengine the right internal / external >>> directions. They use numbers for internal and external. To figure out where >>> the direction is, this config use pseudo vars for receiving local socket >>> >>> >>> https://github.com/voiceboys/sbcOS/blob/master/SbcOS/configs/voice/kamailio/kamailio.cfg#L450 >>> >>> Cheers >>> Karsten Horsmann >>> >>> Patrick Wakano schrieb am Do., 21. Nov. 2019, 07:11: >>> >>>> Hello list, >>>> Hope you are all doing well! >>>> >>>> I am trying to figure out a way to retrieve the local socket the >>>> t_relay() has decided to use in a mhomed=1 env. Is there a way to do that? >>>> I couldn't find any variable other than the $snd ones that maybe have this >>>> info, but I am not using onsend_route anyway. >>>> I am after this value because this is what I can use to figure out if I >>>> need to engage RTPEngine with parameters "external, internal", "external, >>>> external", "internal, external" or "internal, internal". In my case, my >>>> server is in
Re: [SR-Users] How to retrieve local socket that will be used to send a message from the branch route
Thanks for the replies and examples! Much appreciated! I was thinking of something similar to David suggestion, but I think this is not 100% reliable. It may fail in cases where my kernel routing table has some rule where a private IP is reachable via my external interface but different GW for example (multiple IPs in the same interface or more complex network architecture with VPN or direct link with some endpoint) So given Kamailio already consults the kernel looking for the correct interface to a given destination, I thought this is actually the correct information I should use in my script. The only problem is that apparently Kamailio is not exposing this info for the script writer Karsten suggestion should probably work but in short this is just a way to statically save in DB the network routing information I know before hand. If this route changes (which should not happen often I agree) then I have to update the DB. And also this DB data could be replaced by some logic in my script if I had access to the chosen socket... That's exactly the purpose of having mhomed=1 in the script, I don't need to save socket info for all my GWs in DB because I am letting Kamailio automatically decide it. And it does pretty well! The only problem now is that I don't know what this decision was and I need it to implement the RTPEngine logic in my script based on the interface the INVITE will go out. Happy to hear more ideas! Thanks, Kind regards, Patrick Wakano On Thu, 21 Nov 2019 at 20:07, Karsten Horsmann wrote: > Hi Patrick, > > If you don't use tls at this moment, the config from sbc OS is also an > good example of using dispatcher with the socket params to select the right > sendsock and using vars to give rtpengine the right internal / external > directions. They use numbers for internal and external. To figure out where > the direction is, this config use pseudo vars for receiving local socket > > > https://github.com/voiceboys/sbcOS/blob/master/SbcOS/configs/voice/kamailio/kamailio.cfg#L450 > > Cheers > Karsten Horsmann > > Patrick Wakano schrieb am Do., 21. Nov. 2019, 07:11: > >> Hello list, >> Hope you are all doing well! >> >> I am trying to figure out a way to retrieve the local socket the >> t_relay() has decided to use in a mhomed=1 env. Is there a way to do that? >> I couldn't find any variable other than the $snd ones that maybe have this >> info, but I am not using onsend_route anyway. >> I am after this value because this is what I can use to figure out if I >> need to engage RTPEngine with parameters "external, internal", "external, >> external", "internal, external" or "internal, internal". In my case, my >> server is in between two networks, and calls can traverse or can be routed >> back to the same interface depending on what was decide by the LCR module. >> Signalling is fine, but engaging the RTPEngine must be done with the >> correct parameters to get the correct IPs in the SDP, other else I get one >> way audio in the call. >> >> Any help is much appreciated! >> Thank you! >> Kind regards, >> Patrick Wakano >> >> >> ___ >> 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 retrieve local socket that will be used to send a message from the branch route
Hello list, Hope you are all doing well! I am trying to figure out a way to retrieve the local socket the t_relay() has decided to use in a mhomed=1 env. Is there a way to do that? I couldn't find any variable other than the $snd ones that maybe have this info, but I am not using onsend_route anyway. I am after this value because this is what I can use to figure out if I need to engage RTPEngine with parameters "external, internal", "external, external", "internal, external" or "internal, internal". In my case, my server is in between two networks, and calls can traverse or can be routed back to the same interface depending on what was decide by the LCR module. Signalling is fine, but engaging the RTPEngine must be done with the correct parameters to get the correct IPs in the SDP, other else I get one way audio in the call. Any help is much appreciated! Thank you! Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] usrloc extra attributes and db_mode=0
Hi Daniel,
Answering your question:
* without my last patch, was it working on the local node?* Yes, it works
on the local node without your patch. Actually, I could not see any change
with your patch
The problem looks like to be the DMQ replication only. The remote nodes
don't receive the extra attributes...
I will open a ticket because it does seems to be a bug with the dmq_usrloc
module.
Thank you for your time!
Kind regards,
Patrick Wakano
On Wed, 29 May 2019 at 17:25, Daniel-Constantin Mierla
wrote:
> Hello,
>
> to clarify: without my last patch, was it working on the local node? Or
> now with the patch is working for local node, but still an issue of not
> replicating the xavps?
>
> Cheers,
> Daniel
> On 29.05.19 09:02, Patrick Wakano wrote:
>
> Hi Daniel!
> I tried the patch, but it didn't work After some more debugging I
> noticed that actually the problem is in the replication via the dmq_usrloc
> module. The Kamailio which receives the registration can access the
> attributes despite the DB mode (also it works without your patch). The
> problem is that the replicated nodes don't have access to it.
> Sorry my first impression was that the location attributes was not working
> with DB mode 0, but actually it is the DMQ replication failing to send
> contact attributes to other nodes...
> I got this in the logs, may be helpful (the serialized data has nothing
> related to the xavp...)
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar
> [save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
> [ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
> [core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs]
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
> [core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp
> [cluster_node]
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
> [ucontact.c:1701]: update_ucontact(): exists callback for type=
> UL_CONTACT_UPDATE
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
> [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback
> type 2/15, id 1 entered
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
> [usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
> [usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv
> for pid (23230)
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
> [usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other
> nodes...
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
> [usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data
> {"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":
> "sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP"
> ,"received":"","path":"
> ","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z
> 3.15.40006
> rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0}
> May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
> [usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast...
>
> I can open a ticket if the problem is confirmed!
> Thanks,
> Cheers,
> Patrick Wakano
>
> On Tue, 28 May 2019 at 17:17, Patrick Wakano wrote:
>
>> Wow, that was fast!
>> I will try later on and let you know!
>> Thanks Daniel for your time and effort! Really appreciate it!
>>
>> Cheers,
>> Patrick Wakano
>>
>>
>> On Tue, 28 May 2019 at 17:00, Daniel-Constantin Mierla
>> wrote:
>>
>>> Hello,
>>>
>>> can you try with master branch or apply the patch from next commit?
>>>
>>> -
>>> https://github.com/kamailio/kamailio/commit/76f0fa8a0330de3885f5f3830eb90061c59045d4
>>> If works ok, then I will backport.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 28.05.19 08:30, Patrick Wakano wrote:
>>>
>>> Forgot to mention I am using version 5.2.2.
>>> # kamailio -v
>>> version: kamailio 5.2.2 (x86_64/linux) 67f967
>>> flags: STATS: Of
Re: [SR-Users] usrloc extra attributes and db_mode=0
Hi Daniel!
I tried the patch, but it didn't work After some more debugging I
noticed that actually the problem is in the replication via the dmq_usrloc
module. The Kamailio which receives the registration can access the
attributes despite the DB mode (also it works without your patch). The
problem is that the replicated nodes don't have access to it.
Sorry my first impression was that the location attributes was not working
with DB mode 0, but actually it is the DMQ replication failing to send
contact attributes to other nodes...
I got this in the logs, may be helpful (the serialized data has nothing
related to the xavp...)
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar
[save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
[core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
[core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp
[cluster_node]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ucontact.c:1701]: update_ucontact(): exists callback for type=
UL_CONTACT_UPDATE
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback
type 2/15, id 1 entered
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv
for pid (23230)
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other
nodes...
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data
{"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060
;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z
3.15.40006
rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0}
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast...
I can open a ticket if the problem is confirmed!
Thanks,
Cheers,
Patrick Wakano
On Tue, 28 May 2019 at 17:17, Patrick Wakano wrote:
> Wow, that was fast!
> I will try later on and let you know!
> Thanks Daniel for your time and effort! Really appreciate it!
>
> Cheers,
> Patrick Wakano
>
>
> On Tue, 28 May 2019 at 17:00, Daniel-Constantin Mierla
> wrote:
>
>> Hello,
>>
>> can you try with master branch or apply the patch from next commit?
>>
>> -
>> https://github.com/kamailio/kamailio/commit/76f0fa8a0330de3885f5f3830eb90061c59045d4
>> If works ok, then I will backport.
>>
>> Cheers,
>> Daniel
>>
>> On 28.05.19 08:30, Patrick Wakano wrote:
>>
>> Forgot to mention I am using version 5.2.2.
>> # kamailio -v
>> version: kamailio 5.2.2 (x86_64/linux) 67f967
>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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
>> 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: 67f967
>> compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
>>
>> On Tue, 28 May 2019 at 16:26, Patrick Wakano wrote:
>>
>>> Hello list,
>>> Hope you all doing well!
>>>
>>> I am trying to use the extra attributes (xavp_contact) of the usrloc
>>> module to save some additional info about the user.
>>> I am setting the value before the save() and doing a call to
>>> registered() (not lookup()) before trying to access these extra attributes.
>>> This works fine with db_mode=3 but does not work in case of db_mode=0.
>&
Re: [SR-Users] usrloc extra attributes and db_mode=0
Wow, that was fast! I will try later on and let you know! Thanks Daniel for your time and effort! Really appreciate it! Cheers, Patrick Wakano On Tue, 28 May 2019 at 17:00, Daniel-Constantin Mierla wrote: > Hello, > > can you try with master branch or apply the patch from next commit? > > - > https://github.com/kamailio/kamailio/commit/76f0fa8a0330de3885f5f3830eb90061c59045d4 > If works ok, then I will backport. > > Cheers, > Daniel > > On 28.05.19 08:30, Patrick Wakano wrote: > > Forgot to mention I am using version 5.2.2. > # kamailio -v > version: kamailio 5.2.2 (x86_64/linux) 67f967 > flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, > DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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 > 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: 67f967 > compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 > > On Tue, 28 May 2019 at 16:26, Patrick Wakano wrote: > >> Hello list, >> Hope you all doing well! >> >> I am trying to use the extra attributes (xavp_contact) of the usrloc >> module to save some additional info about the user. >> I am setting the value before the save() and doing a call to registered() >> (not lookup()) before trying to access these extra attributes. This works >> fine with db_mode=3 but does not work in case of db_mode=0. >> Does anyone knows if it should also work with mode 0? I was expecting it >> to work but a call to kamcmd ul.dump show nothing related. >> I don't want to use the DB for the location purposes because I prefer to >> have multiple servers using the dmq_usrloc (that works like a charm!) and >> it conflicts with DB persistence of the location table (when the DMQ >> replication happens, all servers (sharing the same DB) try to save the same >> user info in the location table) >> >> Thank you, >> Kind regards, >> Patrick Wakano >> > > ___ > 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
Re: [SR-Users] usrloc extra attributes and db_mode=0
Forgot to mention I am using version 5.2.2. # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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 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: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 On Tue, 28 May 2019 at 16:26, Patrick Wakano wrote: > Hello list, > Hope you all doing well! > > I am trying to use the extra attributes (xavp_contact) of the usrloc > module to save some additional info about the user. > I am setting the value before the save() and doing a call to registered() > (not lookup()) before trying to access these extra attributes. This works > fine with db_mode=3 but does not work in case of db_mode=0. > Does anyone knows if it should also work with mode 0? I was expecting it > to work but a call to kamcmd ul.dump show nothing related. > I don't want to use the DB for the location purposes because I prefer to > have multiple servers using the dmq_usrloc (that works like a charm!) and > it conflicts with DB persistence of the location table (when the DMQ > replication happens, all servers (sharing the same DB) try to save the same > user info in the location table) > > Thank you, > Kind regards, > Patrick Wakano > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] usrloc extra attributes and db_mode=0
Hello list, Hope you all doing well! I am trying to use the extra attributes (xavp_contact) of the usrloc module to save some additional info about the user. I am setting the value before the save() and doing a call to registered() (not lookup()) before trying to access these extra attributes. This works fine with db_mode=3 but does not work in case of db_mode=0. Does anyone knows if it should also work with mode 0? I was expecting it to work but a call to kamcmd ul.dump show nothing related. I don't want to use the DB for the location purposes because I prefer to have multiple servers using the dmq_usrloc (that works like a charm!) and it conflicts with DB persistence of the location table (when the DMQ replication happens, all servers (sharing the same DB) try to save the same user info in the location table) Thank you, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Disable Dispatcher GW from DB
Great Daniel! I will create a ticket for that then! Cheers, Patrick Wakano On Tue, 26 Mar. 2019, 00:30 Daniel-Constantin Mierla, wrote: > Hello, > > that could be a good option indeed, probably a function parameter to > control this kind of behaviour. > > Cheers, > Daniel > On 25.03.19 02:03, Patrick Wakano wrote: > > Hello list, > Hope you are all well! > > I just saw a related situation regarding a disabled GW in dispatcher > module. > In case I have a disabled GW the function ds_is_from_list() still matches > and returns true. > Is that expected? If so, maybe it could have an option to match only the > non-disabled GWs. Would that be reasonable? > > Cheers, > Patrick Wakano > > On Wed, 6 Mar 2019 at 10:01, Patrick Wakano wrote: > >> Thanks Dmitri! >> It worked like a charm! >> Cheers, >> Patrick Wakano >> >> On Tue, 5 Mar. 2019, 18:42 Dmitri Savolainen, >> wrote: >> >>> hi Patrick >>> You may set flag=4 in "dispatcher" table for appropriate GW >>> >>> On Tue, 5 Mar 2019 at 04:57, Patrick Wakano wrote: >>> >>>> Hello list, >>>> Hope you are all doing well! >>>> >>>> I am looking for a way to disable a Dispatcher GW from the DB. I know I >>>> can disable it using the "kamcmd dispatcher.set_state d ..."command, but in >>>> case I do a reload or restart after that, the disabled GW will be back as >>>> active. >>>> Of course I could also delete the GW from DB, but for CDR purposes I >>>> want to keep the entry but mark as permanently disabled, so Kamailio won't >>>> try to use it nor ping it anymore. Does anyone how can I do that in the DB? >>>> I am looking for the exact same behavior the "kamcmd dispatcher.set_state >>>> d" does but from some change in the DB. >>>> >>>> Thanks, >>>> Kind regards, >>>> Patrick Wakano >>>> ___ >>>> Kamailio (SER) - Users Mailing List >>>> sr-users@lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>> >>> >>> -- >>> Savolainen Dmitri >>> ___ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://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 World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training - Mar 25-27, 2019, in Washington, DC, USA -- > www.asipto.com > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Disable Dispatcher GW from DB
Hello list, Hope you are all well! I just saw a related situation regarding a disabled GW in dispatcher module. In case I have a disabled GW the function ds_is_from_list() still matches and returns true. Is that expected? If so, maybe it could have an option to match only the non-disabled GWs. Would that be reasonable? Cheers, Patrick Wakano On Wed, 6 Mar 2019 at 10:01, Patrick Wakano wrote: > Thanks Dmitri! > It worked like a charm! > Cheers, > Patrick Wakano > > On Tue, 5 Mar. 2019, 18:42 Dmitri Savolainen, > wrote: > >> hi Patrick >> You may set flag=4 in "dispatcher" table for appropriate GW >> >> On Tue, 5 Mar 2019 at 04:57, Patrick Wakano wrote: >> >>> Hello list, >>> Hope you are all doing well! >>> >>> I am looking for a way to disable a Dispatcher GW from the DB. I know I >>> can disable it using the "kamcmd dispatcher.set_state d ..."command, but in >>> case I do a reload or restart after that, the disabled GW will be back as >>> active. >>> Of course I could also delete the GW from DB, but for CDR purposes I >>> want to keep the entry but mark as permanently disabled, so Kamailio won't >>> try to use it nor ping it anymore. Does anyone how can I do that in the DB? >>> I am looking for the exact same behavior the "kamcmd dispatcher.set_state >>> d" does but from some change in the DB. >>> >>> Thanks, >>> Kind regards, >>> Patrick Wakano >>> ___ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> >> -- >> Savolainen Dmitri >> ___ >> 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] Disable Dispatcher GW from DB
Thanks Dmitri! It worked like a charm! Cheers, Patrick Wakano On Tue, 5 Mar. 2019, 18:42 Dmitri Savolainen, wrote: > hi Patrick > You may set flag=4 in "dispatcher" table for appropriate GW > > On Tue, 5 Mar 2019 at 04:57, Patrick Wakano wrote: > >> Hello list, >> Hope you are all doing well! >> >> I am looking for a way to disable a Dispatcher GW from the DB. I know I >> can disable it using the "kamcmd dispatcher.set_state d ..."command, but in >> case I do a reload or restart after that, the disabled GW will be back as >> active. >> Of course I could also delete the GW from DB, but for CDR purposes I want >> to keep the entry but mark as permanently disabled, so Kamailio won't try >> to use it nor ping it anymore. Does anyone how can I do that in the DB? I >> am looking for the exact same behavior the "kamcmd dispatcher.set_state d" >> does but from some change in the DB. >> >> Thanks, >> Kind regards, >> Patrick Wakano >> ___ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > -- > Savolainen Dmitri > ___ > 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] Disable Dispatcher GW from DB
Hello list, Hope you are all doing well! I am looking for a way to disable a Dispatcher GW from the DB. I know I can disable it using the "kamcmd dispatcher.set_state d ..."command, but in case I do a reload or restart after that, the disabled GW will be back as active. Of course I could also delete the GW from DB, but for CDR purposes I want to keep the entry but mark as permanently disabled, so Kamailio won't try to use it nor ping it anymore. Does anyone how can I do that in the DB? I am looking for the exact same behavior the "kamcmd dispatcher.set_state d" does but from some change in the DB. Thanks, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TLS reload
Thanks for the feedback guys! Much appreciated! Kamailio and Let's Encrypt with TLS reload, is the way to go then! Cheers! Patrick Wakano On Thu, 28 Feb 2019 at 08:58, Henning Westerholt wrote: > Am Mittwoch, 27. Februar 2019, 09:53:18 CET schrieb Joel Serrano: > > Been doing it like that too (kamailio+tls+LE+auto-reload) for quite some > > time now with 0 issues.. :) > > [..] > > Hello, > > it looks that the warning in the module README is outdated. Maybe somebody > could submit a pull request for an doc improvement. > > Best regards, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://skalatan.de/services > Kamailio security assessment - https://skalatan.de/de/assessment > > ___ > 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] TLS reload
Thanks Sergiu for your reply! That's exactly what I am planning to do. But I just want to make sure the reload would not cause me some problem in production Cheers, Patrick Wakano On Wed, 27 Feb 2019 at 12:44, Sergiu Pojoga wrote: > Using TLS reload every few months when let's encrypt cert renews, works > fine all the time without doing full restart. > > Cheers, > > > On Tue, Feb 26, 2019, 8:29 PM Patrick Wakano, wrote: > >> Hi list, >> I've seen the TLS documentation ( >> https://www.kamailio.org/docs/modules/5.2.x/modules/tls.html#tls.known_limitations) >> where it states that >> >> TLS specific config reloading is not safe, so for now better don't use >> it, especially under heavy traffic. >> This note is there since version 3.0 and in 2013 there was some >> discussion about it but wthout anything conclusive >> What I would like to know if this is still the case. Is anyone running >> the TLS reload for certificate renovation for example, or is it better to >> restart Kamailio? >> >> Thanks, >> Kind regards, >> Patrick Wakano >> ___ >> 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] TLS reload
Hi list, I've seen the TLS documentation ( https://www.kamailio.org/docs/modules/5.2.x/modules/tls.html#tls.known_limitations) where it states that TLS specific config reloading is not safe, so for now better don't use it, especially under heavy traffic. This note is there since version 3.0 and in 2013 there was some discussion about it but wthout anything conclusive What I would like to know if this is still the case. Is anyone running the TLS reload for certificate renovation for example, or is it better to restart Kamailio? Thanks, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio-sipcapture-daemon-config package not found for CentOS7
Thanks Sergey! Issue created: https://github.com/kamailio/kamailio/issues/1861 Kind Regards, Patrick Wakano On Wed, 20 Feb 2019 at 20:33, Sergey Safarov wrote: > Please create issue on GitHub > Then I will care about it. > > ср, 20 февр. 2019 г., 9:26 Patrick Wakano : > >> Hello list, >> I was trying to yum install Kamailio 5.2.1 on a CentOS 7 from the >> http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentOS_7/ >> repo, but the kamailio-sipcapture-daemon-config can't be installed because >> it depends on the kamailio-sipcapture package, which can't be found... >> Is anyone aware of that? >> Thank you, >> Kind regards, >> Patrick Wakano >> >> # yum install kamailio-sipcapture-daemon-config >> Loaded plugins: fastestmirror >> Loading mirror speeds from cached hostfile >> * base: mirror.optus.net >> * epel: mirror.optus.net >> * extras: mirror.intergrid.com.au >> * updates: mirror.intergrid.com.au >> Resolving Dependencies >> --> Running transaction check >> ---> Package kamailio-sipcapture-daemon-config.x86_64 >> 0:5.2.1-1.el7.centos will be installed >> --> Processing Dependency: kamailio-sipcapture = 5.2.1 for package: >> kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 >> --> Finished Dependency Resolution >> Error: Package: >> kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 >> (home_kamailio_v5.2.x-rpms) >>Requires: kamailio-sipcapture = 5.2.1 >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> # yum deplist kamailio-sipcapture-daemon-config >> Loaded plugins: fastestmirror >> Loading mirror speeds from cached hostfile >> * base: mirror.optus.net >> * epel: mirror.optus.net >> * extras: mirror.intergrid.com.au >> * updates: mirror.intergrid.com.au >> package: kamailio-sipcapture-daemon-config.x86_64 5.2.1-1.el7.centos >> dependency: /bin/sh >>provider: bash.x86_64 4.2.46-31.el7 >> dependency: kamailio-sipcapture = 5.2.1 >>Unsatisfied dependency >> >> ___ >> 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] kamailio-sipcapture-daemon-config package not found for CentOS7
Hello list, I was trying to yum install Kamailio 5.2.1 on a CentOS 7 from the http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentOS_7/ repo, but the kamailio-sipcapture-daemon-config can't be installed because it depends on the kamailio-sipcapture package, which can't be found... Is anyone aware of that? Thank you, Kind regards, Patrick Wakano # yum install kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-1.el7.centos will be installed --> Processing Dependency: kamailio-sipcapture = 5.2.1 for package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 (home_kamailio_v5.2.x-rpms) Requires: kamailio-sipcapture = 5.2.1 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # yum deplist kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au package: kamailio-sipcapture-daemon-config.x86_64 5.2.1-1.el7.centos dependency: /bin/sh provider: bash.x86_64 4.2.46-31.el7 dependency: kamailio-sipcapture = 5.2.1 Unsatisfied dependency ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] is_e164 logic to detect valid number
Thanks for your reply Daniel! I agree with you, currently this function name is somewhat misleading... Cheers, Patrick Wakano On Mon, 10 Dec 2018 at 18:31, Daniel-Constantin Mierla wrote: > I think the function was mainly made to check if it is a telephone number > in international format. > > It could be better to make this function more strict in following the > e.164 specs, there is another function to check if it looks like a > telephone number, and as pointed in another response, there is a module for > more strict checking on validity of a phone number per country... > > Cheers, > Daniel > On 05.12.18 04:10, Patrick Wakano wrote: > > Thanks for the replies guys! > I will probably add a length test to invalidate too short numbers! > By the way, I had a quick look in the ITU recommendation ( > https://www.itu.int/rec/T-REC-E.164/en) and looks like the short numbers > are for local purposes only being part of the "Non-ITU-T E.164 numbers" > section, so I guess the function should return false in this case. Also it > seems the + sign is recommended but not mandatory for a E.164 number, which > is quite confusing. > > Kind regards, > Patrick Wakano > > > On Tue, 4 Dec 2018 at 08:57, Henning Westerholt wrote: > >> Am Montag, 3. Dezember 2018, 06:08:27 CET schrieb Patrick Wakano: >> > I am using the is_e164() function to validate the number we receive, >> and I >> > come to see that the number +555 was accepted >> > After some googling it looks like(it is not very clear though) that 7 >> > digits are the minimum we could have for e164 numbers but after checking >> > the source code, I saw it accepts anything starting with + and having >> > between 2 and 16 numbers. So is it really valid to have a number with >> just >> > 2 digits? What is the case? >> >> Hello Patrick, >> >> I think the implementation was done with a pragmatic approach, to make >> sure >> that we don't reject numbers that are used in the field. The ITU standard >> Amendment A mentions the possibility to use national short numbers, for >> example. The standard mentions that the maximal length should be 15, but >> I >> think in this case this was also implemented a bit more relaxed. >> >> The original implementation from the enum module allows even longer >> numbers, I >> will check if this should be synchronized. >> >> Best regards, >> >> Henning >> >> >> -- >> Henning Westerholt - https://skalatan.de/blog/ >> Kamailio services - https://skalatan.de/services >> Kamailio security assessment - https://skalatan.de/de/assessment >> > > ___ > 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 World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] is_e164 logic to detect valid number
Thanks for the hint Joel! That's a really nice addition! One more good reason to upgrade to version 5.2!! Cheers, Patrick Wakano On Wed, 5 Dec 2018 at 14:30, Joel Serrano wrote: > You might also want to have a look at the “phonenum” module... > > https://www.kamailio.org/docs/modules/5.2.x/modules/phonenum.html > > > On Tue, Dec 4, 2018 at 19:12 Patrick Wakano wrote: > >> Thanks for the replies guys! >> I will probably add a length test to invalidate too short numbers! >> By the way, I had a quick look in the ITU recommendation ( >> https://www.itu.int/rec/T-REC-E.164/en) and looks like the short numbers >> are for local purposes only being part of the "Non-ITU-T E.164 numbers" >> section, so I guess the function should return false in this case. Also it >> seems the + sign is recommended but not mandatory for a E.164 number, which >> is quite confusing. >> >> Kind regards, >> Patrick Wakano >> >> >> On Tue, 4 Dec 2018 at 08:57, Henning Westerholt wrote: >> >>> Am Montag, 3. Dezember 2018, 06:08:27 CET schrieb Patrick Wakano: >>> > I am using the is_e164() function to validate the number we receive, >>> and I >>> > come to see that the number +555 was accepted >>> > After some googling it looks like(it is not very clear though) that 7 >>> > digits are the minimum we could have for e164 numbers but after >>> checking >>> > the source code, I saw it accepts anything starting with + and having >>> > between 2 and 16 numbers. So is it really valid to have a number with >>> just >>> > 2 digits? What is the case? >>> >>> Hello Patrick, >>> >>> I think the implementation was done with a pragmatic approach, to make >>> sure >>> that we don't reject numbers that are used in the field. The ITU >>> standard >>> Amendment A mentions the possibility to use national short numbers, for >>> example. The standard mentions that the maximal length should be 15, but >>> I >>> think in this case this was also implemented a bit more relaxed. >>> >>> The original implementation from the enum module allows even longer >>> numbers, I >>> will check if this should be synchronized. >>> >>> Best regards, >>> >>> Henning >>> >>> >>> -- >>> Henning Westerholt - https://skalatan.de/blog/ >>> Kamailio services - https://skalatan.de/services >>> Kamailio security assessment - https://skalatan.de/de/assessment >>> >> ___ >> 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] is_e164 logic to detect valid number
Thanks for the replies guys! I will probably add a length test to invalidate too short numbers! By the way, I had a quick look in the ITU recommendation ( https://www.itu.int/rec/T-REC-E.164/en) and looks like the short numbers are for local purposes only being part of the "Non-ITU-T E.164 numbers" section, so I guess the function should return false in this case. Also it seems the + sign is recommended but not mandatory for a E.164 number, which is quite confusing. Kind regards, Patrick Wakano On Tue, 4 Dec 2018 at 08:57, Henning Westerholt wrote: > Am Montag, 3. Dezember 2018, 06:08:27 CET schrieb Patrick Wakano: > > I am using the is_e164() function to validate the number we receive, and > I > > come to see that the number +555 was accepted > > After some googling it looks like(it is not very clear though) that 7 > > digits are the minimum we could have for e164 numbers but after checking > > the source code, I saw it accepts anything starting with + and having > > between 2 and 16 numbers. So is it really valid to have a number with > just > > 2 digits? What is the case? > > Hello Patrick, > > I think the implementation was done with a pragmatic approach, to make > sure > that we don't reject numbers that are used in the field. The ITU standard > Amendment A mentions the possibility to use national short numbers, for > example. The standard mentions that the maximal length should be 15, but I > think in this case this was also implemented a bit more relaxed. > > The original implementation from the enum module allows even longer > numbers, I > will check if this should be synchronized. > > Best regards, > > Henning > > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://skalatan.de/services > Kamailio security assessment - https://skalatan.de/de/assessment > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] is_e164 logic to detect valid number
Hello list, Hope you are all doing fine! I am using the is_e164() function to validate the number we receive, and I come to see that the number +555 was accepted After some googling it looks like(it is not very clear though) that 7 digits are the minimum we could have for e164 numbers but after checking the source code, I saw it accepts anything starting with + and having between 2 and 16 numbers. So is it really valid to have a number with just 2 digits? What is the case? Thank you, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] DIALPLAN Module: doubts about regular expression usage
Hi Stefano,
I have similar rules in my dialplan and they work.
However the kamcmd dialplan.translate command also fails for me (Kamailio
5.0.4), but I guess it is a problem with the command itself and not with
the translation done by the dp_translate(), because for real calls it does
work!
Patrick Wakano
On Wed, 10 Oct 2018 at 02:21, Stefano Bertuola
wrote:
> Hi Experts.
>
> I did some tests with DIALPLAN module and I have some doubts about how to
> define the regular expressions in the database.
>
> For example, using the start character '^' (beginning of the string), it
> looks not working:
>
> kamcmd> dialplan.dump 1
> {
> DPID: 1
> ENTRIES: {
> ENTRY: {
> PRIO: 1
> MATCHOP: 2
> MATCHEXP: ^(\+39)(.*)$
> MATCHLEN: 0
> SUBSTEXP: ^(\+39)(.*)$
> REPLEXP: \2
> ATTRS: 1
> }
> }
> }
> kamcmd> dialplan.translate 1 "+39123456"
> error: 500 - No translation
>
>
> Removing it, it works... but not as desired:
>
> kamcmd> dialplan.dump 1
> {
> DPID: 1
> ENTRIES: {
> ENTRY: {
> PRIO: 1
> MATCHOP: 1
> MATCHEXP: (\+39)(.*)$
> MATCHLEN: 0
> SUBSTEXP: (\+39)(.*)$
> REPLEXP: \2
> ATTRS: 1
> }
> }
> }
> kamcmd> dialplan.translate 1 "+39123456"
> {
> Output: 123456"
> Attributes: 1
> }
> kamcmd> dialplan.translate 1 "xxx+39123456"
> {
> Output: 123456"
> Attributes: 1
> }
>
>
> Can someone help me understand how the regular expression should be used
> in DIALPLAN, please?
>
> Br. Stefano
> ___
> 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] set_advertised_address with variable
Hi Daniel! Thanks for the effort! Really appreciate it! I am not using the 5.2 version yet, so it I won't be able to test it right away... Best regards, Patrick Wakano On Fri, 5 Oct 2018 at 18:37, Daniel-Constantin Mierla wrote: > Hello, > > yesterday afternoon I pushed an alternative for allowing setting the > address and port in local Via headers using XAVP, see: > > - https://www.kamailio.org/wiki/cookbooks/devel/core#xavp_via_fields > > I didn't have the time to do any tests, but was in master before freezing > code for 5.2.x series, so it will be in the next major release. Test and if > there is any bug, report and it will be fixed. > > I also looked at extending the set_advertised_address(), but it actually > uses pointers to some static values available at kamailio startup, so > making that dynamic would have been more complex to do in a short time. > > Cheers, > Daniel > > On 03.10.18 03:28, Patrick Wakano wrote: > > Thanks for the replies Daniel and Henning! > The problem with the listen address is that it can't be set at run time > per call, for example, after reading the value from the DB And also it > is way too dirty to use the set_advertised_address with a static string > value > Long story short, we have a weird telco setup which only allows the SIP > trunk to terminate in their own network, which then puts my Kamailio behind > a NAT box only for them. And because they are the biggest carrier in that > country, we will have to workaround the issue. > Kamailio itself has only one network interface to communicate with > everyone (other provider and extensions), so I was trying to actually only > set the advertise address before sending call to this specific telco. For > calls to anyone else I would not set the advertise address. Looks simple, > but seems not that easy to implement. > > Cheers, > Patrick Wakano > > On Tue, 2 Oct 2018 at 15:39, Daniel-Constantin Mierla > wrote: > >> Hello, >> >> the pseudo-variable is read only. >> >> The recommended way would be to use listen with advertise, like: >> >> listen=udp:1.2.3.4:5060 advertise 5.6.7.8:5060 >> >> That will take care of both Via and Record-Route headers as well as >> matching myself, no need to do other stuff in route blocks. Doesn't work >> for you? >> >> Cheers, >> Daniel >> >> >> On 01.10.18 22:16, Henning Westerholt wrote: >> > Am Freitag, 28. September 2018, 07:16:18 CEST schrieb Patrick Wakano: >> >> Sorry to annoy again, but I did find a couple of more emails asking >> around >> >> about the possibility to pass a variable to the >> set_advertised_address, but >> >> no one was replied >> >> How is the status of these old core functions that don't accept >> variables >> >> as parameters? Is it something being worked on? >> > Hi Patrick, >> > >> > about the old core function - I think that indeed some of them are still >> > missing PV support. Regarding your question, have you already tried to >> use >> > this PV: >> > >> > >> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#rai_-_received_advertised_ip_address >> > >> > Best regards, >> > >> > Henning >> > >> >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio World Conference -- www.kamailioworld.com >> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.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.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] set_advertised_address with variable
Thanks for the replies Daniel and Henning! The problem with the listen address is that it can't be set at run time per call, for example, after reading the value from the DB And also it is way too dirty to use the set_advertised_address with a static string value Long story short, we have a weird telco setup which only allows the SIP trunk to terminate in their own network, which then puts my Kamailio behind a NAT box only for them. And because they are the biggest carrier in that country, we will have to workaround the issue. Kamailio itself has only one network interface to communicate with everyone (other provider and extensions), so I was trying to actually only set the advertise address before sending call to this specific telco. For calls to anyone else I would not set the advertise address. Looks simple, but seems not that easy to implement. Cheers, Patrick Wakano On Tue, 2 Oct 2018 at 15:39, Daniel-Constantin Mierla wrote: > Hello, > > the pseudo-variable is read only. > > The recommended way would be to use listen with advertise, like: > > listen=udp:1.2.3.4:5060 advertise 5.6.7.8:5060 > > That will take care of both Via and Record-Route headers as well as > matching myself, no need to do other stuff in route blocks. Doesn't work > for you? > > Cheers, > Daniel > > > On 01.10.18 22:16, Henning Westerholt wrote: > > Am Freitag, 28. September 2018, 07:16:18 CEST schrieb Patrick Wakano: > >> Sorry to annoy again, but I did find a couple of more emails asking > around > >> about the possibility to pass a variable to the set_advertised_address, > but > >> no one was replied > >> How is the status of these old core functions that don't accept > variables > >> as parameters? Is it something being worked on? > > Hi Patrick, > > > > about the old core function - I think that indeed some of them are still > > missing PV support. Regarding your question, have you already tried to > use > > this PV: > > > > > https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#rai_-_received_advertised_ip_address > > > > Best regards, > > > > Henning > > > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.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] set_advertised_address with variable
Sorry to annoy again, but I did find a couple of more emails asking around about the possibility to pass a variable to the set_advertised_address, but no one was replied How is the status of these old core functions that don't accept variables as parameters? Is it something being worked on? Kind regards, Patrick Wakano On Thu, 27 Sep 2018 at 18:17, Patrick Wakano wrote: > Hello list, > Hope you all doing fine! > > I am using version 5.0.7 and I was trying to use the > set_advertised_address with an avp variable but it does not replace with > the avp value > I then find out this thread > https://lists.kamailio.org/pipermail/sr-users/2016-March/092327.html, in > which is mentioned: > > *"I expect those functions not to support pvs, but I think this > issomething to address in 5.0 and get all core functions working with pvs."* > > Looks like this was actually not done is that correct? Is there any > plan to do it? > In my case I want to use the set_advertised_address after reading the > value from DB, so I can't use the advertised_address or listen options > Any idea on how I could achieve that? > > Thank you, > Kind regards, > Patrick Wakano > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] set_advertised_address with variable
Hello list, Hope you all doing fine! I am using version 5.0.7 and I was trying to use the set_advertised_address with an avp variable but it does not replace with the avp value I then find out this thread https://lists.kamailio.org/pipermail/sr-users/2016-March/092327.html, in which is mentioned: *"I expect those functions not to support pvs, but I think this issomething to address in 5.0 and get all core functions working with pvs."* Looks like this was actually not done is that correct? Is there any plan to do it? In my case I want to use the set_advertised_address after reading the value from DB, so I can't use the advertised_address or listen options Any idea on how I could achieve that? Thank you, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0.X RPM packages/repo broken
Hi Sergey! You mean a github ticket? Patrick Wakano On 26 July 2018 at 17:31, Sergey Safarov wrote: > I can confirm issue. > Could you create ticket for this issue. > I look this > > чт, 26 июл. 2018 г. в 2:12, Patrick Wakano : > >> Hello Sergey! >> >> I did a yum clean all, the rm -Rf /var/cache/yum/* and still the problem >> persist. >> Now I noticed the modified date of the packages was updated, but anyway, >> there is something wrong with this repo and so yum does not allow me to >> install the Kamailio packages >> I wonder what could have happened since July 10th when the repo was >> working fine... >> >> Thanks for you time! >> Kind regards, >> Patrick Wakano >> >> >> >> On 25 July 2018 at 23:38, Sergey Safarov wrote: >> >>> I "trigger rebuild" and get this results >>> https://build.opensuse.org/package/live_build_log/home: >>> kamailio:v5.0.x-rpms/kamailio50/CentOS_7/x86_64 >>> >>> Rebuild is finished >>> https://prnt.sc/kauq7y >>> But time stamp of files inside root repo directory is not updated >>> And updated inside x86_64 >>> https://download.opensuse.org/repositories/home:/kamailio:/ >>> v5.0.x-rpms/CentOS_7/x86_64/ >>> >>> And inside repodata >>> https://download.opensuse.org/repositories/home:/kamailio:/ >>> v5.0.x-rpms/CentOS_7/repodata/ >>> >>> Could you force delete content of /var/cache/yum >>> >>> rm -Rf /var/cache/yum/* >>> >>> And then try again >>> Sergey >>> >>> ср, 25 июл. 2018 г. в 5:05, Patrick Wakano : >>> >>>> Hello Sergey! >>>> Thanks for your attention! >>>> >>>> I have just tried and it is still not working Same error... >>>> I noticed the files in here http://download.opensuse.org/ >>>> repositories/home:/kamailio:/v5.0.x-rpms/CentOS_7/x86_64/ didn't get >>>> the modified date changed maybe the rebuild didn't work... >>>> >>>> Kind regards, >>>> Patrick Wakano >>>> >>>> >>>> >>>> On 25 July 2018 at 01:23, Sergey Safarov wrote: >>>> >>>>> Hello Patrick >>>>> Rebuild is trigered. >>>>> >>>>> >>>>> вт, 24 июл. 2018 г. в 7:56, Patrick Wakano : >>>>> >>>>>> Hello Sergey! >>>>>> Hope you are doing fine! >>>>>> >>>>>> I am having this same issue again today >>>>>> Would you be able to check that? >>>>>> >>>>>> Thanks very much! >>>>>> Kind regards, >>>>>> Patrick Wakano >>>>>> >>>>>> # yum install kamailio >>>>>> Loaded plugins: fastestmirror >>>>>> Loading mirror speeds from cached hostfile >>>>>> * base: centos.mirror.serversaustralia.com.au >>>>>> * epel: mirror.intergrid.com.au >>>>>> * extras: centos.melbourneitmirror.net >>>>>> * remi: remi.conetix.com.au >>>>>> * remi-safe: remi.conetix.com.au >>>>>> * updates: mirror.intergrid.com.au >>>>>> Resolving Dependencies >>>>>> --> Running transaction check >>>>>> ---> Package kamailio.x86_64 0:5.0.7-3.el7.centos will be installed >>>>>> --> Processing Dependency: libkamailio_ims.so.0()(64bit) for package: >>>>>> kamailio-5.0.7-3.el7.centos.x86_64 >>>>>> --> Running transaction check >>>>>> ---> Package kamailio-ims.x86_64 0:5.0.7-3.el7.centos will be >>>>>> installed >>>>>> --> Finished Dependency Resolution >>>>>> >>>>>> Dependencies Resolved >>>>>> >>>>>> >>>>>> >>>>>> = >>>>>> Package Arch >>>>>> Version Repository >>>>>> Size >>>>>> >>>>>> >>>>>> = >>>>>> Installing: >>>>>> kamailio
Re: [SR-Users] Kamailio 5.0.X RPM packages/repo broken
Hello Sergey! I did a yum clean all, the rm -Rf /var/cache/yum/* and still the problem persist. Now I noticed the modified date of the packages was updated, but anyway, there is something wrong with this repo and so yum does not allow me to install the Kamailio packages I wonder what could have happened since July 10th when the repo was working fine... Thanks for you time! Kind regards, Patrick Wakano On 25 July 2018 at 23:38, Sergey Safarov wrote: > I "trigger rebuild" and get this results > https://build.opensuse.org/package/live_build_log/home: > kamailio:v5.0.x-rpms/kamailio50/CentOS_7/x86_64 > > Rebuild is finished > https://prnt.sc/kauq7y > But time stamp of files inside root repo directory is not updated > And updated inside x86_64 > https://download.opensuse.org/repositories/home:/kamailio:/ > v5.0.x-rpms/CentOS_7/x86_64/ > > And inside repodata > https://download.opensuse.org/repositories/home:/kamailio:/ > v5.0.x-rpms/CentOS_7/repodata/ > > Could you force delete content of /var/cache/yum > > rm -Rf /var/cache/yum/* > > And then try again > Sergey > > ср, 25 июл. 2018 г. в 5:05, Patrick Wakano : > >> Hello Sergey! >> Thanks for your attention! >> >> I have just tried and it is still not working Same error... >> I noticed the files in here http://download.opensuse.org/ >> repositories/home:/kamailio:/v5.0.x-rpms/CentOS_7/x86_64/ didn't get the >> modified date changed maybe the rebuild didn't work... >> >> Kind regards, >> Patrick Wakano >> >> >> >> On 25 July 2018 at 01:23, Sergey Safarov wrote: >> >>> Hello Patrick >>> Rebuild is trigered. >>> >>> >>> вт, 24 июл. 2018 г. в 7:56, Patrick Wakano : >>> >>>> Hello Sergey! >>>> Hope you are doing fine! >>>> >>>> I am having this same issue again today >>>> Would you be able to check that? >>>> >>>> Thanks very much! >>>> Kind regards, >>>> Patrick Wakano >>>> >>>> # yum install kamailio >>>> Loaded plugins: fastestmirror >>>> Loading mirror speeds from cached hostfile >>>> * base: centos.mirror.serversaustralia.com.au >>>> * epel: mirror.intergrid.com.au >>>> * extras: centos.melbourneitmirror.net >>>> * remi: remi.conetix.com.au >>>> * remi-safe: remi.conetix.com.au >>>> * updates: mirror.intergrid.com.au >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package kamailio.x86_64 0:5.0.7-3.el7.centos will be installed >>>> --> Processing Dependency: libkamailio_ims.so.0()(64bit) for package: >>>> kamailio-5.0.7-3.el7.centos.x86_64 >>>> --> Running transaction check >>>> ---> Package kamailio-ims.x86_64 0:5.0.7-3.el7.centos will be installed >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> >>>> >>>> = >>>> Package Arch >>>> Version Repository >>>> Size >>>> >>>> >>>> = >>>> Installing: >>>> kamailio x86_64 >>>> 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms >>>> 5.1 M >>>> Installing for dependencies: >>>> kamailio-ims x86_64 >>>> 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms >>>> 1.2 M >>>> >>>> Transaction Summary >>>> >>>> >>>> = >>>> Install 1 Package (+1 Dependent package) >>>> >>>> Total download size: 6.4 M >>>> Installed size: 29 M >>>> Is this ok [y/d/N]: y >>>> >>>> Downloading packages: >>>> Delta RPMs disabled because /usr/bin/applydeltarpm not installed. >>>> kamailio-5.0.7-3.el7.centos.x8 FAILED >>>> >>>> http://download.opensuse.org/repositories/home%3A/kamailio% >>>> 3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-3.el7.cento
Re: [SR-Users] Kamailio 5.0.X RPM packages/repo broken
Hello Sergey! Thanks for your attention! I have just tried and it is still not working Same error... I noticed the files in here http://download.opensuse.org/repositories/home:/kamailio:/v5.0.x-rpms/CentOS_7/x86_64/ didn't get the modified date changed maybe the rebuild didn't work... Kind regards, Patrick Wakano On 25 July 2018 at 01:23, Sergey Safarov wrote: > Hello Patrick > Rebuild is trigered. > > > вт, 24 июл. 2018 г. в 7:56, Patrick Wakano : > >> Hello Sergey! >> Hope you are doing fine! >> >> I am having this same issue again today >> Would you be able to check that? >> >> Thanks very much! >> Kind regards, >> Patrick Wakano >> >> # yum install kamailio >> Loaded plugins: fastestmirror >> Loading mirror speeds from cached hostfile >> * base: centos.mirror.serversaustralia.com.au >> * epel: mirror.intergrid.com.au >> * extras: centos.melbourneitmirror.net >> * remi: remi.conetix.com.au >> * remi-safe: remi.conetix.com.au >> * updates: mirror.intergrid.com.au >> Resolving Dependencies >> --> Running transaction check >> ---> Package kamailio.x86_64 0:5.0.7-3.el7.centos will be installed >> --> Processing Dependency: libkamailio_ims.so.0()(64bit) for package: >> kamailio-5.0.7-3.el7.centos.x86_64 >> --> Running transaction check >> ---> Package kamailio-ims.x86_64 0:5.0.7-3.el7.centos will be installed >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> >> >> = >> Package Arch >> Version Repository >> Size >> >> >> = >> Installing: >> kamailio x86_64 >> 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms >> 5.1 M >> Installing for dependencies: >> kamailio-ims x86_64 >> 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms >> 1.2 M >> >> Transaction Summary >> >> >> = >> Install 1 Package (+1 Dependent package) >> >> Total download size: 6.4 M >> Installed size: 29 M >> Is this ok [y/d/N]: y >> >> Downloading packages: >> Delta RPMs disabled because /usr/bin/applydeltarpm not installed. >> kamailio-5.0.7-3.el7.centos.x8 FAILED >> >> http://download.opensuse.org/repositories/home%3A/kamailio% >> 3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-3.el7.centos.x86_64.rpm: >> [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable >> Trying other mirror. >> kamailio-ims-5.0.7-3.el7.cento FAILED >> ] 218 kB/s | 710 kB 00:00:26 >> ETA >> http://download.opensuse.org/repositories/home%3A/kamailio% >> 3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-ims-5.0.7-3.el7.centos.x86_64.rpm: >> [Errno -1] Package does not match intended download. Suggestion: run yum >> --enablerepo=home_kamailio_v5.0.x-rpms clean metadata >> Trying other mirror. >> >> >> Error downloading packages: >> kamailio-5.0.7-3.el7.centos.x86_64: [Errno 256] No more mirrors to try. >> kamailio-ims-5.0.7-3.el7.centos.x86_64: [Errno 256] No more mirrors to >> try. >> >> >> On 10 July 2018 at 14:49, Patrick Wakano wrote: >> >>> Thank you Sergey!! >>> Installation was successful now!! >>> >>> Cheers! >>> Patrick Wakano >>> >>> On 10 July 2018 at 14:24, Sergey Safarov wrote: >>> >>>> I was trigered rpm rebuild. >>>> Please check after 40 min. >>>> >>>> вт, 10 июля 2018 г., 6:57 Patrick Wakano : >>>> >>>>> Hello list, >>>>> Hope you all doing fine! >>>>> >>>>> I've been trying to install Kamailio packages from the opensuse repo >>>>> (as per https://www.kamailio.org/wiki/packages/rpms) but the >>>>> installation is failing with this message: >>>>> Downloading packages: >>>>> Delta RPMs disabled because /usr/bin/applydeltarpm not installed. >>>>> kamailio-ims-5.0.7-1.el7.cento FAILED >>>>> >>>>> http://download.opensuse.org/repos
Re: [SR-Users] Kamailio 5.0.X RPM packages/repo broken
Hello Sergey! Hope you are doing fine! I am having this same issue again today Would you be able to check that? Thanks very much! Kind regards, Patrick Wakano # yum install kamailio Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos.mirror.serversaustralia.com.au * epel: mirror.intergrid.com.au * extras: centos.melbourneitmirror.net * remi: remi.conetix.com.au * remi-safe: remi.conetix.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio.x86_64 0:5.0.7-3.el7.centos will be installed --> Processing Dependency: libkamailio_ims.so.0()(64bit) for package: kamailio-5.0.7-3.el7.centos.x86_64 --> Running transaction check ---> Package kamailio-ims.x86_64 0:5.0.7-3.el7.centos will be installed --> Finished Dependency Resolution Dependencies Resolved = Package Arch Version Repository Size = Installing: kamailio x86_64 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms 5.1 M Installing for dependencies: kamailio-ims x86_64 5.0.7-3.el7.centos home_kamailio_v5.0.x-rpms 1.2 M Transaction Summary = Install 1 Package (+1 Dependent package) Total download size: 6.4 M Installed size: 29 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. kamailio-5.0.7-3.el7.centos.x8 FAILED http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-3.el7.centos.x86_64.rpm: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable Trying other mirror. kamailio-ims-5.0.7-3.el7.cento FAILED ] 218 kB/s | 710 kB 00:00:26 ETA http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-ims-5.0.7-3.el7.centos.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=home_kamailio_v5.0.x-rpms clean metadata Trying other mirror. Error downloading packages: kamailio-5.0.7-3.el7.centos.x86_64: [Errno 256] No more mirrors to try. kamailio-ims-5.0.7-3.el7.centos.x86_64: [Errno 256] No more mirrors to try. On 10 July 2018 at 14:49, Patrick Wakano wrote: > Thank you Sergey!! > Installation was successful now!! > > Cheers! > Patrick Wakano > > On 10 July 2018 at 14:24, Sergey Safarov wrote: > >> I was trigered rpm rebuild. >> Please check after 40 min. >> >> вт, 10 июля 2018 г., 6:57 Patrick Wakano : >> >>> Hello list, >>> Hope you all doing fine! >>> >>> I've been trying to install Kamailio packages from the opensuse repo (as >>> per https://www.kamailio.org/wiki/packages/rpms) but the installation >>> is failing with this message: >>> Downloading packages: >>> Delta RPMs disabled because /usr/bin/applydeltarpm not installed. >>> kamailio-ims-5.0.7-1.el7.cento FAILED >>> >>> http://download.opensuse.org/repositories/home%3A/kamailio%3 >>> A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-ims-5.0.7-1.el7.centos.x86_64.rpm: >>> [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable --:--:-- ETA >>> Trying other mirror. >>> kamailio-5.0.7-1.el7.centos.x8 FAILED >>> 77% [- >>> ] 1.0 MB/s | 4.9 MB 00:00:01 ETA >>> http://download.opensuse.org/repositories/home%3A/kamailio%3 >>> A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-1.el7.centos.x86_64.rpm: >>> [Errno -1] Package does not match intended download. Suggestion: run yum >>> --enablerepo=home_kamailio_v5.0.x-rpms clean metadata >>> Trying other mirror. >>> >>> I've successfully installed the 5.0.7 version on Friday (06/07) but I've >>> noticed the packages have changed last Saturday (07/07/2018) Given this >>> error message looks like the repository is broken somehow >>> Is anyone aware of such issue? I haven't tried the 5.1.X repo because my >>> script was not migrated to 5.1.X yet >>> >>> Thanks, >>> Kind regards, >>> Patrick Wakano >>> ___ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio
Re: [SR-Users] Kamailio 5.0.X RPM packages/repo broken
Thank you Sergey!! Installation was successful now!! Cheers! Patrick Wakano On 10 July 2018 at 14:24, Sergey Safarov wrote: > I was trigered rpm rebuild. > Please check after 40 min. > > вт, 10 июля 2018 г., 6:57 Patrick Wakano : > >> Hello list, >> Hope you all doing fine! >> >> I've been trying to install Kamailio packages from the opensuse repo (as >> per https://www.kamailio.org/wiki/packages/rpms) but the installation is >> failing with this message: >> Downloading packages: >> Delta RPMs disabled because /usr/bin/applydeltarpm not installed. >> kamailio-ims-5.0.7-1.el7.cento FAILED >> >> http://download.opensuse.org/repositories/home%3A/kamailio% >> 3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-ims-5.0.7-1.el7.centos.x86_64.rpm: >> [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable --:--:-- ETA >> Trying other mirror. >> kamailio-5.0.7-1.el7.centos.x8 FAILED >> 77% [- >> ] 1.0 MB/s | 4.9 MB 00:00:01 ETA >> http://download.opensuse.org/repositories/home%3A/kamailio% >> 3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-1.el7.centos.x86_64.rpm: >> [Errno -1] Package does not match intended download. Suggestion: run yum >> --enablerepo=home_kamailio_v5.0.x-rpms clean metadata >> Trying other mirror. >> >> I've successfully installed the 5.0.7 version on Friday (06/07) but I've >> noticed the packages have changed last Saturday (07/07/2018) Given this >> error message looks like the repository is broken somehow.... >> Is anyone aware of such issue? I haven't tried the 5.1.X repo because my >> script was not migrated to 5.1.X yet >> >> Thanks, >> Kind regards, >> Patrick Wakano >> ___ >> 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] Kamailio 5.0.X RPM packages/repo broken
Hello list, Hope you all doing fine! I've been trying to install Kamailio packages from the opensuse repo (as per https://www.kamailio.org/wiki/packages/rpms) but the installation is failing with this message: Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. kamailio-ims-5.0.7-1.el7.cento FAILED http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-ims-5.0.7-1.el7.centos.x86_64.rpm: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable --:--:-- ETA Trying other mirror. kamailio-5.0.7-1.el7.centos.x8 FAILED 77% [- ] 1.0 MB/s | 4.9 MB 00:00:01 ETA http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-1.el7.centos.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=home_kamailio_v5.0.x-rpms clean metadata Trying other mirror. I've successfully installed the 5.0.7 version on Friday (06/07) but I've noticed the packages have changed last Saturday (07/07/2018) Given this error message looks like the repository is broken somehow Is anyone aware of such issue? I haven't tried the 5.1.X repo because my script was not migrated to 5.1.X yet Thanks, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] add_uri_param with variables
Hello list, Hope you all doing well! We've been attempting to add a URI parameter to implement the trunk group (tgrp and trunk-context) but discovered the add_uri_param() function only works with constant string we can't use a pseudovar to inform the value to be added. Anyone knows why such limitation? Can it be changed? It is possible to do the same thing via the subst_uri function, but it would be so much more elegant to use the function... Thank you, Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] lcr_id vs lcr_count
Hello Kamailio list!
I've been working with the LCR module and I wanted to use the lcr_id to
match some ID's I have somewhere else.
However, due to the lcr_count my lcr_ids must be less than the lcr_count. I
understand the reason behind the lcr_count, what I think is a mistake is to
have the lcr_id dependent of the lcr_count.
Ideally we should be able to use any lcr_id value, just observing that the
total amount of lcr groups should not exceed the lcr_count.
The problem is this if that appears in the load_gws, to_gw and from_gw
functions in lcr_mod.c:
if ((lcr_id < 1) || (lcr_id > lcr_count_param)) {
LM_ERR("invalid lcr_id parameter value %d\n", lcr_id);
return -1;
}
I ended up using another table to make the conversion of ids, but this is
horrible Any other reason to force the lcr_id to be less than the
lcr_count?
Best Regards,
Patrick Wakano
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] LCR Ping GWs
Hello list, I was trying to activate continuous SIP ping from the LCR module, which apparently was available in the past, but currently it is not possible anymore. As I could check It can only ping inactive GWs. Question is, why such change was promoted? We have to send a call to the GW to detect it has died instead of actively monitoring them and so avoid this useless call attempt. It is not that big deal, but it does gives me a better monitoring of my providers (specially the ones not used so frequently) health. Regards, Patrick ___ 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] SIP ping, sockets and multi homed
Hello list,
After deep investigation I found out that the issue is happening because of
the mechanism Kamailio uses to find the most appropriate socket combined
with the virtual IP usage
For socket selection, Kamailio first asks Linux which would be the routing
for a certain destination, then matches this outcome with the list of
listened sockets.
By default Linux will always return the local IP instead of the virtual
one. So if Kamailio only binds to the virtual IP, the Linux's returned IP
won't match our socket list and then the socket selection fails
So currently Kamailio active/stand-by HA setup with virtual IP in a
multi-homed environment does not work properly...
We can overcome this by listening to all addresses, but then Kamailio will
decide to use the local IP instead of the virtual one, and then the HA idea
end up broken
We can also force socket for everything. For regular call routing, this
options actually works fine if the script always force some socket, but it
seems to be not always possible for local generated messages. By disabling
mhomed and using the dispatcher socket attr to send the OPTIONS message it
works for example. But for the LCR module we have no option because
apparently the LCR module has only one socket option, and so I am not able
have a different socket per gateway.
We can also explicitly set the src address for a routing rule to be the
virtual IP instead of the local one. This makes Linux to return the virtual
IP instead of the local one. This solution seems fine, but since it is done
at linux level, every other service on the box would be affected and every
route on the box would needed to be changed..
Another problem I found out is that I am not able to force the socket for
local generated messages. It actually crashes Kamailio, and I always get a
"core was not generated" msg anyone aware of that?
The actual fix for this, would be having Kamailio to search the most
appropriate socket in a different manner. It could loop the sockets and see
which one reaches the destination instead of asking Linux to do it, or it
could have some routing directives which could be consulted before
selecting a socket (just ideas, not sure how feasible they are...)
I am considering using the Linux routing change option, but has anyone
faced such situation before?
Regards,
Patrick Wakano
On 24 August 2017 at 09:18, Patrick Wakano <pwak...@gmail.com> wrote:
> Hello Daniel,
> I still couldn't make this SIP probing work So currently my setup
> cannot actively check for GW availability...
> Any idea about what may be causing it?
>
> Thanks for your time,
> Patrick Wakano
>
> On 16 August 2017 at 13:01, Patrick Wakano <pwak...@gmail.com> wrote:
>
>> Forgot to mention it is a centos7 box...
>>
>> On 16 Aug. 2017 11:02 am, "Patrick Wakano" <pwak...@gmail.com> wrote:
>>
>>> Hi Daniel!
>>> Very grateful for your attention!
>>>
>>> Apologies for lacking important info, check below the version and
>>> sockets.
>>> It may be worth mentioning these IPs are virtual ones and I am using
>>> net.ipv4.ip_nonlocal_bind
>>> = 1(in this case the virtual IP is assigned to the box)
>>> Interesting that it has a "mhomed: no" for all sockets but I do have
>>> mhomed=1 in my cfg file could that be the issue?
>>> Also there is no message before this one: /usr/sbin/kamailio[6164]:
>>> ERROR: [core/forward.c:181]: get_out_socket(): no socket found
>>> This is the first one that pops when dispatcher tries to ping
>>>
>>> Thanks,
>>> Patrick
>>>
>>> kamailio -v
>>> version: kamailio 5.0.2 (x86_64/linux)
>>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE,
>>> USE_MCAST, DNS_IP_HACK, SHM_MEM, 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
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>> 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 on 12:03:49 Jun 26 2017 with gcc 4.8.5
>>>
>>> kamcmd> core.sockets_list
>>> {
>>> socket: {
>>> proto: udp
>>> address: 172.28.128.100
>>> ipaddress: 172.28.128.100
>>> port: 5060
>>> mcast: no
>>> mhomed: no
>>> }
>>> socket: {
>>> proto: udp
>>> address: 192.168.33.100
>>> ipa
Re: [SR-Users] SQL for ordered LCR rules
Nice! but I think I can invert the test and do it like this: 'FULL_NUMBER' LIKE CONCAT(lr.prefix,'%') Probably not as fast but should do the job! On 6 September 2017 at 12:25, Alex Balashov <abalas...@evaristesys.com> wrote: > Indeed. > > On September 5, 2017 10:24:07 PM EDT, Patrick Wakano <pwak...@gmail.com> > wrote: > >Thanks for the attention Alex, so this "prefix" add on for Postgresql > >is > >supposed to replace my lr.prefix SIMILAR TO '(|PREFIX%)' ? So then I > >could > >actually use a complete number against the LCR prefixes, instead of > >having > >to use a prefix in the test? > > > >Cheers, > >Patrick Wakano > > > > > > > >On 6 September 2017 at 09:57, Alex Balashov <abalas...@evaristesys.com> > >wrote: > > > >> https://github.com/dimitri/prefix > ><https://github.com/dimitri/prefixIt> > >> > >> > >> Regardless of how many routes you have, you don't want to do it the > >way > >> you're doing it. Trust me. > >> > >> -- Alex > >> > >> On Sep 5, 2017, at 7:54 PM, Patrick Wakano <pwak...@gmail.com> wrote: > >> > >> Thanks for the response guys! > >> The link https://github.com/dimitri/prefixIt is returning 404 > >> Regarding the performance itself I am not worried since this select > >it is > >> just for management and I don't expect having millions of rules. > >> The idea is just to have an easy way to have a picture of how the LCR > >will > >> order and select the gateways based on a given prefix. The three LCR > >tables > >> are not so easy to handle and manage from command line so my idea was > >to > >> have a single SELECT or VIEW to return me all I need at once! > >> From what I could check, I think the select I sent pretty much > >translates > >> what LCR module does internally, I am just trying to verify if it has > >some > >> flaw, which could mislead me in the rules management. > >> > >> Cheers, > >> Patrick Wakano > >> > >> > >> On 6 September 2017 at 00:32, Dmitry Sinina > ><dmitry.sin...@onat.edu.ua> > >> wrote: > >> > >>> https://yeti-switch.org/demo.html > >>> > >>> > >>> On 9/5/17 5:29 PM, Dmitry Sinina wrote: > >>> > >>>> And you can try our opensource LCR engine. We use kamailio as load > >>>> balancer and SEMS as SBC. > >>>> > >>>> On 9/5/17 3:02 AM, Patrick Wakano wrote: > >>>> > >>>>> Hello list, > >>>>> > >>>>> Hope you all doing well! > >>>>> I am trying to ease the management of LCR routing rules, since > >once we > >>>>> begin to have multiple prefixes, multiple GWs and so on, the > >visualization > >>>>> and management of the rules priorities becomes exponentially hard > >to do. > >>>>> So first thing I am trying to achieve is an easy way of retrieving > >the > >>>>> rules in an ordered manner. I couldn't find any tool to do such > >thing and > >>>>> source code was not very friendly so I've come up with this > >Postgresql > >>>>> query that I think retrieves all rules in the same order I expect > >LCR to > >>>>> select the GWs. > >>>>> > >>>>> SELECT lr.lcr_id, lr.prefix, lrt.priority, lg.gw_name, lg.ip_addr > >>>>> FROM lcr_rule lr > >>>>> JOIN lcr_rule_target lrt ON lrt.lcr_id = lr.lcr_id AND lrt.rule_id > >= > >>>>> lr.id <http://lr.id> > >>>>> JOIN lcr_gw lg ON lg.lcr_id = lr.lcr_id AND lg.id <http://lg.id> = > >>>>> lrt.gw_id > >>>>> WHERE lr.enabled = 1 AND lg.defunct = 0 AND lr.lcr_id = ID AND > >>>>> lr.prefix SIMILAR TO '(|PREFIX%)' > >>>>> ORDER BY lr.lcr_id, LENGTH(lr.prefix) DESC, lrt.priority; > >>>>> > >>>>> It is missing the weights calculation, but it is rather complex > >and I > >>>>> am not using it anyway Other than that does anyone did > >something > >>>>> similar to check if my query really matches what LCR engine does? > >>>>> > >>>>> Thanks, > >>>>> Patrick Wakano > >>>>> > >>>>> ___ > >>>>> 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 > >> > >> > > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > ___ > 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] SQL for ordered LCR rules
Thanks for the attention Alex, so this "prefix" add on for Postgresql is supposed to replace my lr.prefix SIMILAR TO '(|PREFIX%)' ? So then I could actually use a complete number against the LCR prefixes, instead of having to use a prefix in the test? Cheers, Patrick Wakano On 6 September 2017 at 09:57, Alex Balashov <abalas...@evaristesys.com> wrote: > https://github.com/dimitri/prefix <https://github.com/dimitri/prefixIt> > > > Regardless of how many routes you have, you don't want to do it the way > you're doing it. Trust me. > > -- Alex > > On Sep 5, 2017, at 7:54 PM, Patrick Wakano <pwak...@gmail.com> wrote: > > Thanks for the response guys! > The link https://github.com/dimitri/prefixIt is returning 404 > Regarding the performance itself I am not worried since this select it is > just for management and I don't expect having millions of rules. > The idea is just to have an easy way to have a picture of how the LCR will > order and select the gateways based on a given prefix. The three LCR tables > are not so easy to handle and manage from command line so my idea was to > have a single SELECT or VIEW to return me all I need at once! > From what I could check, I think the select I sent pretty much translates > what LCR module does internally, I am just trying to verify if it has some > flaw, which could mislead me in the rules management. > > Cheers, > Patrick Wakano > > > On 6 September 2017 at 00:32, Dmitry Sinina <dmitry.sin...@onat.edu.ua> > wrote: > >> https://yeti-switch.org/demo.html >> >> >> On 9/5/17 5:29 PM, Dmitry Sinina wrote: >> >>> And you can try our opensource LCR engine. We use kamailio as load >>> balancer and SEMS as SBC. >>> >>> On 9/5/17 3:02 AM, Patrick Wakano wrote: >>> >>>> Hello list, >>>> >>>> Hope you all doing well! >>>> I am trying to ease the management of LCR routing rules, since once we >>>> begin to have multiple prefixes, multiple GWs and so on, the visualization >>>> and management of the rules priorities becomes exponentially hard to do. >>>> So first thing I am trying to achieve is an easy way of retrieving the >>>> rules in an ordered manner. I couldn't find any tool to do such thing and >>>> source code was not very friendly so I've come up with this Postgresql >>>> query that I think retrieves all rules in the same order I expect LCR to >>>> select the GWs. >>>> >>>> SELECT lr.lcr_id, lr.prefix, lrt.priority, lg.gw_name, lg.ip_addr >>>> FROM lcr_rule lr >>>> JOIN lcr_rule_target lrt ON lrt.lcr_id = lr.lcr_id AND lrt.rule_id = >>>> lr.id <http://lr.id> >>>> JOIN lcr_gw lg ON lg.lcr_id = lr.lcr_id AND lg.id <http://lg.id> = >>>> lrt.gw_id >>>> WHERE lr.enabled = 1 AND lg.defunct = 0 AND lr.lcr_id = ID AND >>>> lr.prefix SIMILAR TO '(|PREFIX%)' >>>> ORDER BY lr.lcr_id, LENGTH(lr.prefix) DESC, lrt.priority; >>>> >>>> It is missing the weights calculation, but it is rather complex and I >>>> am not using it anyway Other than that does anyone did something >>>> similar to check if my query really matches what LCR engine does? >>>> >>>> Thanks, >>>> Patrick Wakano >>>> >>>> ___ >>>> 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 > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] SQL for ordered LCR rules
Thanks for the response guys! The link https://github.com/dimitri/prefixIt is returning 404 Regarding the performance itself I am not worried since this select it is just for management and I don't expect having millions of rules. The idea is just to have an easy way to have a picture of how the LCR will order and select the gateways based on a given prefix. The three LCR tables are not so easy to handle and manage from command line so my idea was to have a single SELECT or VIEW to return me all I need at once! >From what I could check, I think the select I sent pretty much translates what LCR module does internally, I am just trying to verify if it has some flaw, which could mislead me in the rules management. Cheers, Patrick Wakano On 6 September 2017 at 00:32, Dmitry Sinina <dmitry.sin...@onat.edu.ua> wrote: > https://yeti-switch.org/demo.html > > > On 9/5/17 5:29 PM, Dmitry Sinina wrote: > >> And you can try our opensource LCR engine. We use kamailio as load >> balancer and SEMS as SBC. >> >> On 9/5/17 3:02 AM, Patrick Wakano wrote: >> >>> Hello list, >>> >>> Hope you all doing well! >>> I am trying to ease the management of LCR routing rules, since once we >>> begin to have multiple prefixes, multiple GWs and so on, the visualization >>> and management of the rules priorities becomes exponentially hard to do. >>> So first thing I am trying to achieve is an easy way of retrieving the >>> rules in an ordered manner. I couldn't find any tool to do such thing and >>> source code was not very friendly so I've come up with this Postgresql >>> query that I think retrieves all rules in the same order I expect LCR to >>> select the GWs. >>> >>> SELECT lr.lcr_id, lr.prefix, lrt.priority, lg.gw_name, lg.ip_addr >>> FROM lcr_rule lr >>> JOIN lcr_rule_target lrt ON lrt.lcr_id = lr.lcr_id AND lrt.rule_id = >>> lr.id <http://lr.id> >>> JOIN lcr_gw lg ON lg.lcr_id = lr.lcr_id AND lg.id <http://lg.id> = >>> lrt.gw_id >>> WHERE lr.enabled = 1 AND lg.defunct = 0 AND lr.lcr_id = ID AND lr.prefix >>> SIMILAR TO '(|PREFIX%)' >>> ORDER BY lr.lcr_id, LENGTH(lr.prefix) DESC, lrt.priority; >>> >>> It is missing the weights calculation, but it is rather complex and I am >>> not using it anyway Other than that does anyone did something similar >>> to check if my query really matches what LCR engine does? >>> >>> Thanks, >>> Patrick Wakano >>> >>> ___ >>> 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] SQL for ordered LCR rules
Hello list, Hope you all doing well! I am trying to ease the management of LCR routing rules, since once we begin to have multiple prefixes, multiple GWs and so on, the visualization and management of the rules priorities becomes exponentially hard to do. So first thing I am trying to achieve is an easy way of retrieving the rules in an ordered manner. I couldn't find any tool to do such thing and source code was not very friendly so I've come up with this Postgresql query that I think retrieves all rules in the same order I expect LCR to select the GWs. SELECT lr.lcr_id, lr.prefix, lrt.priority, lg.gw_name, lg.ip_addr FROM lcr_rule lr JOIN lcr_rule_target lrt ON lrt.lcr_id = lr.lcr_id AND lrt.rule_id = lr.id JOIN lcr_gw lg ON lg.lcr_id = lr.lcr_id AND lg.id = lrt.gw_id WHERE lr.enabled = 1 AND lg.defunct = 0 AND lr.lcr_id = ID AND lr.prefix SIMILAR TO '(|PREFIX%)' ORDER BY lr.lcr_id, LENGTH(lr.prefix) DESC, lrt.priority; It is missing the weights calculation, but it is rather complex and I am not using it anyway Other than that does anyone did something similar to check if my query really matches what LCR engine does? Thanks, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR dont_strip_or_prefix_flag
Good news! Thanks Anthony! Regards Patrick On 25 Aug. 2017 22:34, "Anthony Joseph Messina" <amess...@messinet.com> wrote: On Friday, August 25, 2017 2:33:30 AM CDT Juha Heinanen wrote: > Patrick Wakano writes: > > It doesn't matter if I set or reset the flag it never prefix the ReqUR if > > the declaration is present. I have to remove the declaration to make the > > module prefix it correctly. But then the whole purpose of the flag is > > lostAnyone aware of this behaviour? > > This should not be fixed in 5.0 and master. > > -- Juha Should *now* be fixed. Thanks Juha. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 ___ 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] LCR dont_strip_or_prefix_flag
Hello list,
I am using Kamailio 5.0.2 on centos7 and I am trying to use the
dont_strip_or_prefix_flag (
https://www.kamailio.org/docs/modules/5.0.x/modules/lcr.html#idp49131644)
for LCR routing but I discovered that just by declaring the flag like this
the module won't prefix my calls:
#!define LCR_DONT_STRIP_OR_TAG 7
modparam("lcr", "dont_strip_or_prefix_flag", LCR_DONT_STRIP_OR_TAG)
It doesn't matter if I set or reset the flag it never prefix the ReqUR if
the declaration is present. I have to remove the declaration to make the
module prefix it correctly. But then the whole purpose of the flag is
lostAnyone aware of this behaviour?
Regards,
Patrick Wakano
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
