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 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
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.
Hello,
is there an rsync endpoint available or is there a possiblity of setting
this up? Creating a mirror via HTTP is a rather quick and dirty solution
and while the deb-repo can be mirrored using debmirror, the rpm repo is
hard to sync to a non-CentOS-based machine due to missing dependencies
such as yum and reposync in latest Debian-based systems.
Would be great to get some input in regards to this topic.
Cheers
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_ep…
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> [core/parser/parse_uri.c:1296]:
parse_uri(): bad port in uri (error at char 5 in state 2) parsed:
<sip:3518929:16411>(17) /<sip:3518929:1641150726@192.168.2.99> (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" <sip:3518929:1641148397@192.168.2.99>
From: "3518929" <sip:3518929:1641148397@192.168.2.99>;tag=ht76o8b2b6
Call-ID: phkj9mi2n3s3ju7uu3qq2f
CSeq: 274 REGISTER
Contact:
<sip:edh7mmti@192.0.2.202;transport=wss>;reg-id=1;+sip.instance="<urn: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:<username>:<port> instead of
sip:<username>:<timestamp>.
Is this a bug that should be reported or is there any setting that I am
missing?
Hi there,
I have a weird issue with kamailio (latest docker
image kamailio-ci:5.5.2-alpine) and http_async_client.
Before posting a lot of logs, let me describe what I want to achieve.
I have a Kamailio and a SIP Phone.
The SIP phone sends a REGISTER to kamailio, then in my routing block, I
check if I have an Authorization header.
Since I don't have an Authorization (first message), I
use "www_challenge()".
This replies to the SIP phone, and then the SIP phone sends a new REGISTER
with the correct Authorization header.
So far so good.
Now, when I get the REGISTER with Authorization header, I want to ask an
HTTP endpoint if this user is allowed to connect and check the password
using http_async_query().
The problem is that when the transaction resumes, the tmx module is unhappy
and throws this error :
30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked
branch (-1) for a final response in MODE_ONFAILURE
And a 500 error is sent back to the sip phone.
The AUTH_REPLY route is still called and I can use the $http* values.
Do you see something that I am doing wrong or missing in my logic?
Is pausing/resuming to use the async http client is allowed if I'm handling
a REGISTER transaction?
Here's a simplified version of my routing block (not far from reality):
##### SNIP
request_route{
route(AUTH);
route[AUTH]{
if (is_method("REGISTER"){
if(no_auth_header){
www_challenge("$td","1");
exit;
}
else{
t_newtran();
http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar",
"AUTH_REPLY");
}
}
}
route[AUTH_REPLY]{
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
}
}
##### END SNIP
Best regards!
Hi to all,
We have a Kamailio 5.3 that sends all traffic to a homer7 using siptrace
module with parameters force_send_sock and hep_mode_on,1 and hep_version,3
and trace_mode,1. Everything works fine getting all traffic to Homer7 but,
in case Homer7 is not reachable, Kamailio then no longer accepts traffic or
registrations and it is like it crashes. When we revive Homer7 and is it
again reachable accepting traffic, Kamailio then works again fine without
any restart or actions.
Any ideas why this may be happening? Is there anything we need to add to
the config to avoid this behavior as having Homer7 now is a single point of
failure for Kamailio?
Thank you!
Kind Regards,
Angelo
hello,
we are using kamailio 5.3 . while establishing a call the tel uri is
getting converted into sip uri sometimes incorrectly . In the sip uri some
extra characters are getting appended in the invite message. Can somebody
please provide some guidance on this, attaching the pcap for
reference(packet no. 8).
Thanks,
*Jyoti Bansal*
Software Engineer .
Great Software Laboratory | www.gslab.com
--
Confidentiality Notice and Disclaimer: This email (including any
attachments) contains information that may be confidential, privileged
and/or copyrighted. If you are not the intended recipient, please notify
the sender immediately and destroy this email. Any unauthorized use of the
contents of this email in any manner whatsoever, is strictly prohibited. If
improper activity is suspected, all available information may be used by
the sender for possible disciplinary action, prosecution, civil claim or
any remedy or lawful purpose. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, lost, arrive
late, or contain viruses. The sender is not liable whatsoever for damage
resulting from the opening of this message and/or the use of the
information contained in this message and/or attachments. Expressions in
this email cannot be treated as opined by the sender company management –
they are solely expressed by the sender unless authorized.