[SR-Users] Re: Kamailio - asterisk - ACK
Thanks for the feedback.
It's tricky, alright, making all of these things work together.
Asterisk should not be re-writing the RR header fields, alright. At
least you found a solution. I can't think of anything better than
that, if it works for you.
James
On Wed, 3 May 2023 at 17:07, Dr. Barabás Péter
wrote:
>
> Hi James,
>
>
>
> thanks for the reply. Yes, record_route() is used in INVITE request.
>
> Meanwhile I found the cause I think here:
>
> https://community.asterisk.org/t/asterisk-rewrites-record-route-header-with-incorrect-tcp-port/91202
>
>
>
> So the Record-Route header contains kamailio’s IP and listening TLS port 443
> until asterisk. When asterisk sends back 200/OK, it rewrites the port and
> client wants to send ACK to this port which is not a listening port of
> kamailio.
>
> My quick (but don’t know if proper) solution is that in reply route of INVITE
> I check that If replay comes from asterisk, I add the following:
>
>
>
> if (route(FROMASTERISK)) {
>
> remove_hf("Record-Route");
>
> append_hf("Record-Route: sips:KAMAILIO_IP:443;transport=TLS\r\n");
>
> }
>
>
>
> Now the ACK can go back to kamailio which forward it to asterisk.
>
> There was another problem with ACK when it contains private IP, the
> fix_nated_contact() in on_reply route solved this.
>
>
>
> Peter
>
>
>
>
>
> From: James Browne
> Date: Wednesday, 2023. May 3. 17:17
> To: Kamailio (SER) - Users Mailing List
> Subject: [SR-Users] Re: Kamailio - asterisk - ACK
>
> If the 200-OK to client A also contains Record-Route header fields,
> then the routing of the ACK from client A should be done using that
> route, not using the internal IP address of asterisk.
> Are you using record_route() function from the rr module?
>
> James
>
> On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás
> wrote:
> >
> > Hi all,
> >
> >
> >
> > we are developing a softphone mobile application which registers to
> > asterisk through kamailio. Kamailo proxies the request to asterisk and
> > replies from asterisk to the clients.
> >
> > Registration works fine with asterisk authentication. The problem appears
> > in the following flow:
> >
> > Mobile client A calls client B.
> > Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with
> > credentials.
> > Asterisk sends invite to client B towards kamailio.
> > Kamailio forwards INVITE if client is registered or sends a push
> > notification to client B. When client B registers, kamailio continue the
> > suspended transaction and forwards INVITE.
> > Client B gets INVITE, sends a SIP OK.
> > Asterisk gets SIP OK through kamailio and sends an ACK to client B, which
> > is OK.
> > Asterisk sends the SIP OK to client A through kamailio.
> > Kamailio forwards SIP OK to client A but the contact address contains the
> > asterisk IP instead kamailio.
> > Clilent A try to send ACK but it does not arrive to asterisk, and the call
> > will be hungup after 30 secs.
> >
> >
> >
> > So the question is what is missing, what is the correct solution? I try to
> > use the provided configuration given in following link:
> >
> > https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
> >
> >
> >
> > The difference is that kamailio has no access to asterisk database.
> >
> >
> >
> > Thanks for your help.
> >
> >
> >
> > With kind regards,
> >
> > Peter
> >
> >
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio - asterisk - ACK
Hi James,
thanks for the reply. Yes, record_route() is used in INVITE request.
Meanwhile I found the cause I think here:
https://community.asterisk.org/t/asterisk-rewrites-record-route-header-with-incorrect-tcp-port/91202
So the Record-Route header contains kamailio’s IP and listening TLS port 443
until asterisk. When asterisk sends back 200/OK, it rewrites the port and
client wants to send ACK to this port which is not a listening port of kamailio.
My quick (but don’t know if proper) solution is that in reply route of INVITE I
check that If replay comes from asterisk, I add the following:
if (route(FROMASTERISK)) {
remove_hf("Record-Route");
append_hf("Record-Route: sips:KAMAILIO_IP:443;transport=TLS\r\n");
}
Now the ACK can go back to kamailio which forward it to asterisk.
There was another problem with ACK when it contains private IP, the
fix_nated_contact() in on_reply route solved this.
Peter
From: James Browne
Date: Wednesday, 2023. May 3. 17:17
To: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] Re: Kamailio - asterisk - ACK
If the 200-OK to client A also contains Record-Route header fields,
then the routing of the ACK from client A should be done using that
route, not using the internal IP address of asterisk.
Are you using record_route() function from the rr module?
James
On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás
wrote:
>
> Hi all,
>
>
>
> we are developing a softphone mobile application which registers to asterisk
> through kamailio. Kamailo proxies the request to asterisk and replies from
> asterisk to the clients.
>
> Registration works fine with asterisk authentication. The problem appears in
> the following flow:
>
> Mobile client A calls client B.
> Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with
> credentials.
> Asterisk sends invite to client B towards kamailio.
> Kamailio forwards INVITE if client is registered or sends a push notification
> to client B. When client B registers, kamailio continue the suspended
> transaction and forwards INVITE.
> Client B gets INVITE, sends a SIP OK.
> Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is
> OK.
> Asterisk sends the SIP OK to client A through kamailio.
> Kamailio forwards SIP OK to client A but the contact address contains the
> asterisk IP instead kamailio.
> Clilent A try to send ACK but it does not arrive to asterisk, and the call
> will be hungup after 30 secs.
>
>
>
> So the question is what is missing, what is the correct solution? I try to
> use the provided configuration given in following link:
>
> https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
>
>
>
> The difference is that kamailio has no access to asterisk database.
>
>
>
> Thanks for your help.
>
>
>
> With kind regards,
>
> Peter
>
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio - asterisk - ACK
If the 200-OK to client A also contains Record-Route header fields, then the routing of the ACK from client A should be done using that route, not using the internal IP address of asterisk. Are you using record_route() function from the rr module? James On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás wrote: > > Hi all, > > > > we are developing a softphone mobile application which registers to asterisk > through kamailio. Kamailo proxies the request to asterisk and replies from > asterisk to the clients. > > Registration works fine with asterisk authentication. The problem appears in > the following flow: > > Mobile client A calls client B. > Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with > credentials. > Asterisk sends invite to client B towards kamailio. > Kamailio forwards INVITE if client is registered or sends a push notification > to client B. When client B registers, kamailio continue the suspended > transaction and forwards INVITE. > Client B gets INVITE, sends a SIP OK. > Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is > OK. > Asterisk sends the SIP OK to client A through kamailio. > Kamailio forwards SIP OK to client A but the contact address contains the > asterisk IP instead kamailio. > Clilent A try to send ACK but it does not arrive to asterisk, and the call > will be hungup after 30 secs. > > > > So the question is what is missing, what is the correct solution? I try to > use the provided configuration given in following link: > > https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb > > > > The difference is that kamailio has no access to asterisk database. > > > > Thanks for your help. > > > > With kind regards, > > Peter > > > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [sr-dev] RFC: selective backports to latest stable as a dedicated git branch
Hello, On 2/5/23 12:10, Daniel-Constantin Mierla wrote: [...] Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported. The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list: - no backporting of completely new modules - no backporting of significant changes to the config file language and native scripting interpreter In the "ok-to-backport": - updates to enable use with newer versions of external libraries - changes to make some functions/modules to cope better with the core infrastructure or end points Commits to the backports branch can be proposed via pull requests. The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it. No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about. I've no problem to provide the debs without formal releases. It could be handle as we already do for X.Y branches. A nightly build if changes are detected. Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it. It sounds fine to me -- - | ,''`. Victor Seva | | : :' : linuxman...@torreviejawireless.org | | `. `' PGP Key ID: 0x51A09B18CF5A5068 | |`- Debian Developer | - OpenPGP_0x51A09B18CF5A5068.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [sr-dev] RFC: selective backports to latest stable as a dedicated git branch
> On 2 May 2023, at 12:10, Daniel-Constantin Mierla wrote: > > Hello, > > during past on-site/online devel meetings as well as on mailing lists or > tracker, there were various discussions around the idea or requests to > make new features available quicker to stable branches. > > Of course, one can do local git cherry-picking, but I thought to bring > this in discussion and see if makes sense to get something more > coordinated between developers and community. Therefore I am > cross-posting to sr-dev and sr-users to see if there is interest for it > from both communities. > > Somehow inspired from Debian, my first idea would be to create a > "x.y-backports" branch, where "x.y" is the branch for the stable release > series. For example, with 5.6 release series built from branch "5.6", > there could be "5.6-backports" branch which is kept in sync in "5.6" but > also can get "selected" new features from devel (master branch) backported. > > The "selected" new features should be mostly a matter of the people > willing to put effort in backporting, but I would consider a list > recommendations not to end up with devel and backports branches being > more or less the same. For example, in the "no-backporting" list: > > - no backporting of completely new modules > - no backporting of significant changes to the config file language > and native scripting interpreter I would add - no changes to database schemas or versions /O > > In the "ok-to-backport": > > - updates to enable use with newer versions of external libraries > - changes to make some functions/modules to cope better with the core > infrastructure or end points > > Commits to the backports branch can be proposed via pull requests. > > The backports branch should be done only for latest stable version, > picking from the development version. Right now it would be 5.6, but we > can wait till 5.7 is released and then have it for it. > > No packaging and no official releases should be made from backports > branch, only a git branch to be maintained as a community effort. Of > course, if someone wants to put more resources into it, we can discuss > about. > > Anyhow, the first questions would be if such branch sounds good to have > and if there are people that think they can also contribute to maintain it. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com > > ___ > Kamailio (SER) - Development Mailing List > To unsubscribe send an email to sr-dev-le...@lists.kamailio.org __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Clarification of 'return false' behaviour
Hello,
the sip3.txt contains just a SIP message, nothing really special about it.
Cheers,
Henning
From: Patrick Wakano
Sent: Mittwoch, 3. Mai 2023 08:02
To: mico...@gmail.com
Cc: Kamailio (SER) - Users Mailing List
Subject: [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
mailto:mico...@gmail.com>> 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
mailto:mico...@gmail.com>> 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 {
[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, 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
