I have kamailio behind a TLS termination proxy so the sockets are correctly
deduced to be TCP. However the clients only talk TLS to the proxy and are
confused when the top Via header added by Kamailio is TCP. Is there a way
for Kamailio to forcibly pretend its protocol is TLS? Like
advertised_address but "advertised_protocol" instead.
(With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio
and continues to use the persistent TLS transport to proxy. Linphone fails
because it tries to honor TCP in Via and is unable to establish TCP
transport).
BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy
as TCP even though the contact addresses specify transport=TLS.
Hi everybody,
I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This
seems to work very good. Dialogs are replicated without problems.
When I'm restarting one node I would have expected, that all dialogs are
synced again, just like in dmq_usrloc.
But this does not happen. After a restart the nodes dialog-list is empty.
Did I miss somethin? Is there a special parameter that I have to set?
BR, Björn
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
Hi,
I am building a configuration script where for some traffic flows
parallel forking will be needed, and in this case I need to go beyond
the default max limit of the max amount of branches.
Apart from this specific case the traffic load that kamailio will need
to handle is very low, let's say just one second here and there with up
to 5 concurrent calls at most.
This limit is as far as I understand set here:
usr/local/src/kamailio-5.6/kamailio/src/core/config.h
And the default limit is:
#define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum
number of branches per transaction */
Here are the questions I have related to this:
1) If I increase the value of this constant in config.h, how high is it
reasonable to set this value and still have a stable system?
2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other
parameters that needs to be changed for the system to be able to cope,
and if so whichparameters?
Regards,
Lars
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.
