Hi All,
I am facing an issue in understanding how the min_se should be working in
kamailio. As per the SST documentation, it seems like if the min_se is
configured as 500, then any value of Session-Expires OR MIN-SE if lower
than 500, can be responded to by a 422.
However, I strangely see the reverse happening. To investigate further, I
looked in to the ki_sst_check_min() code in the master, and these seems
like a potential issue.
Ref Code: Inside ki_sst_check_min(), there is an if condition like below:
if (sst_min_se < MIN(minse, se.interval)) {
However, shouldn't it be the other way around? ie
if (sst_min_se > MIN(minse, se.interval)) {
because we need to send 422 if the received value(in INVITE etc) is
smaller than the sst configure min_se value?
I also found a different documentation, at
https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6…
where
the check is as below?
if (sst_min_se > MIN(minse, se.interval)) {
Can someone confirm if this is broken, or my understanding is incorrect?
Regards,
Harneet
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hi List,
we are running several stateless SIP Loadbalancers using Kamaillio 5.1 and 5.6.
Now we would like to perform an async_http request if an INVITE matches certain criteria. The request itself is performed very similar to how it's described here [1]
This uses the transaction module in order to assure that the response can be mapped to the original request. However, this also means that the processing of the entire request becomes stateful which we would like to avoid.
We tried to use t_release() in the callback route (in [1] this route is called "RELAY_API_RESPONSE"). However, documentation says that this is only allowed in the REQUEST_ROUTE.
Is there an easy way to circumnavigate this issue?
Cheers
[1]: https://wazo-platform.org/blog/kamailio-routing-with-rtjson-and-http-async-…
--
Julius Flohr - Voice Engineer - flohr(a)sipgate.de
Telefon: +49 (0)211-63 55 55-0
Mobil: +49 (0)1579-000-0205
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.co.uk
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:
1. Mobile client A calls client B.
2. Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with credentials.
3. Asterisk sends invite to client B towards kamailio.
4. 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.
5. Client B gets INVITE, sends a SIP OK.
6. Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is OK.
7. Asterisk sends the SIP OK to client A through kamailio.
8. Kamailio forwards SIP OK to client A but the contact address contains the asterisk IP instead kamailio.
9. 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
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-r…,
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
On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote:
> Sure. Attached. Problem appears to be that the topos query can't find
> callid-totag (from the response).
>
> I'll try the same scenario with the mysql backend to see if it behaves
> different.
Config works fine with mysql as topos backend. So the bug is restricted
to topos-redis.
Hi All,
Can someone point to a sample as to how we can *load the LCR Module tables*
namely the following at startup from a csv file or any other mechanism.
* lcr_gw_table
* lcr_rule_table
* lcr_rule_target_table
The idea is to not need to manually feed in the entries into the table but
instead add these in the beginning through either a *wrapper script
*OR *through
the kamailio cfg file* if possible.
Any pointers are much appreciated.
Thanks & Regards,
Harneet Singh
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hi Experts,
I believe the loose_route() in kamailio can be used for initial Out of the
dialog INVITE processing as well. Is that the correct understanding?
If so, the request will be forwarded ahead to the destination corresponding
to the Route Header remaining (if any) after Kamailio has stripped off it's
own Address(es) from the Route Header(s). Is that correct?
Regards,
Harneet Singh
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hello,
We have a transparent proxy in front of Asterisk boxes. The media is handled by rtpengine, and the "manage" work is done by Kamailio in the route[NATMANAGE] section like this:
if(nat_uac_test("8")) {
# Packet from backend server
if(ds_is_from_list()){
if (rtpengine_manage("replace-origin replace-session-connection direction=internal direction=pub")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from INTERNAL to EXTERNAL $ru");
}
}
else
{
if (rtpengine_manage("replace-origin replace-session-connection direction=pub direction=internal")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from EXTERNAL to INTERNAL $ru");
}
}
} else {
# Packet from backend server
if(ds_is_from_list()){
if (rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal direction=pub")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from INTERNAL to EXTERNAL $ru");
}
}
else
{
if (rtpengine_manage("replace-origin replace-session-connection trust-address direction=pub direction=internal")) {
xdbg("NATMANAGE --- Success rtpengine_manage() RTP from EXTERNAL to INTERNAL $ru");
}
}
}
Everything is working fine, but with some clients (like Grandstream phone) the RTCP session wants to go tot he private address of the phone. Here is the log of one of these strange calls:
Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: [312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] --------- Port 178.238.213.14:11088 <> 81.183.216.3:5068 , SSRC 77c19488, 625 p, 107500 b, 0 e, 29 ts
Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: [312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] --------- Port 178.238.213.14:11089 <> 10.0.5.192:5069 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 43 ts
As you can see the RTP itself is okay, but the RTCP will somehow go to the private address. If we tracing the sdp messages in sngrep, then we can see that Kamailio transforming IP addresses for the backend servers to the public (and the private address of the rtpengine) addresses.
We are missing something?
Thank you!
With kind regards,
Zoltan
