`5.8.1+bpo11` was released and the issue is gone. Hope it stays that way.
@miconda feel free to close this if you feel there is nothing else to be done.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3757#issuecomment-2039258891
You are
> Are v5.4 and v5.5 concerned too ?
In my testing, all versions higher than 5.6.5 inclusive are affected. The first
to work for me was `5.8.1~bpo11.20240319013115.16` although I couldn't test
`5.8.0 GA` due to https://github.com/kamailio/kamailio/issues/3785
I don't remember seeing this
Hello,
No, contact_mode is not defined so it's the default (0). I'll try to
investigate a little bit more during the week...
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3757#issuecomment-2022558181
You are receiving this because you are
Hello, have you tried kamailio-5.8.1-dev (nightly)? It solved the problem for
me (see #3757), but it would be good to have another confirmation.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3437#issuecomment-2022553533
You are receiving this
This seems to be fixed in `5.8.1~bpo11.20240319013115.16`. I haven't been able
to test with 5.8.0 because of #3785. Has anything changed and are there any
plans to backport to 5.7.x and 5.6.x? Thanks!
--
Reply to this email directly or view it on GitHub:
evs investigate. Also the questions in the form ask for all what they
> need.
>
> Thank you
>
> George Diamantopoulos via sr-users schrieb
> am Do., 15. Feb. 2024, 16:06:
>
>> Update: I have just downgraded to 5.6.4 using
>> https://deb-archive.kamailio.org/repos/
### Description
All kamailio versions on the 5.7.x train and additionally point release 5.6.5
break early dialog transactions, at least when the following conditions are
(cumulatively) met:
* topos-redis is enabled (haven't tested other storage backends yet, let me
know if needed)
* kamailio is
he same IP.
Hopefully this is enough to get an idea of what might have gone wrong?
Thanks!
On Thu, 15 Feb 2024 at 15:55, George Diamantopoulos
wrote:
> Hello all,
>
> I've noticed that there seems to be a regression with the topos module,
> more specifically the redis flavour, but I'm assumi
Hello all,
I've noticed that there seems to be a regression with the topos module,
more specifically the redis flavour, but I'm assuming the storage backend
shouldn't make a difference.
I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm assuming
some backported commit is to blame.
That is great news, thanks! Any chance this will make it into the 11.4 release
train or should one expect it in >=11.5.x?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3509#issuecomment-1652148360
You are receiving this because you are
### Description
Newer rtpengine versions support manipulating SDP "a=" lines directly. Although
kamailio is quite versatile when it comes to editing SIP message body, this
functionality is often rather frail, especially when forking and having to use
msg_apply_changes several times. I believe
Hello all,
Thank you to all who contributed to this release. I'm not seeing packages
for debian yet. Perhaps there's some issue with the build bots? I don't
remember it having taken that long for binaries to appear with previous
releases. Thanks!
BR,
George
On Fri, 8 Jul 2022 at 12:18, Patrick
, or is there
still work to be done? Thanks!
Best regards,
George
On Fri, 13 Aug 2021 at 10:50, George Diamantopoulos
wrote:
> Excellent. Thanks!
>
> On Thu, 12 Aug 2021 at 09:56, Henning Westerholt wrote:
>
>> Hello George,
>>
>>
>>
>> they will b
Congrats to everyone involved!
Small note, the changelog reads:
= Changes Since Version 5.5.2
===
Shouldn't it be:
= Changes Since Version 5.5.1
===
instead?
BR,
George
On Wed, 25 Aug 2021 at 16:07,
>
>
>
> Henning
>
>
>
> *From:* sr-dev *On Behalf Of *George
> Diamantopoulos
> *Sent:* Thursday, August 12, 2021 7:02 AM
> *To:* Kamailio (SER) - Development Mailing List >
> *Subject:* [sr-dev] Bullseye builds
>
>
>
> Hello all,
>
>
>
Hello all,
Debian 11 "Bullseye" is to be released this Saturday. Do you expect to have
binaries available for it on deb.kamailio.org anytime soon following the
release? Thanks!
BR,
George
___
Kamailio (SER) - Development Mailing List
Closed #2447.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2447#event-3671990364___
Kamailio (SER) - Development Mailing List
Never mind, this is properly documented in the registrar module docs:
> A call to lookup(...) always uses the path header if found, and inserts it as
> Route HF either in front of the first Route HF, or after the last Via HF if
> no Route is present. It also sets the destination uri to the
> You do not need that to be 1 if you want to use Path for routing, only if you
> want to bypass the intermediary proxy doing Path.
>
> IIRC, the nathelper module has (or had) a mode to spoof source IP and then it
> could send UDP NAT keepalives pretending to be the intermediary proxy to
>
> Do you have this parameter set?
>
> *
> https://www.kamailio.org/docs/modules/stable/modules/registrar.html#registrar.p.path_use_received
Yes:
```
# - registrar params -
modparam("registrar", "method_filtering", 1)
/* uncomment the next line to disable parallel forking via
### Description
Consider the following setup: an edge proxy is configured with the path module,
double rr is enabled (because the proxy is multihomed), add_path_received() is
used to cope with NATted endpoints and the registrar is a separate kamailio
instance residing on a private network.
!-- Kamailio Pull Request Template --
!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable
Would it be too expensive to check with nat_uac_test before conditionally
enabling this? I'm assuming yes, since this route will statelessly handle most
OPTIONS requests and several scanning cases, but I thought I'd ask anyway...
--
You are receiving this because you are subscribed to this
If this excerpt from the core docs still holds true: "It is necessary to
include the port (the port value used in the “port=” or “listen=” defintions)
in the alias definition otherwise the loose_route() function will not work as
expected for local forwards", it might be a good idea to use #
shouldn't this read: "set it to no to enable"?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@miconda Regarding force_rport(), the point I was making was exactly that it
does NOT engage in REQINIT, even if WITH_NAT is enabled. For example, replies
to OPTIONS sent to kami will always be directed to address in first Via header
even for NATted devices, even with NAT support enabled in the
+1 for path support by default
Some other random preliminary thoughts:
* Is there any reason for NATDETECT to precede retransmission processing? Also,
AFAIK Contact header is not (normally?) present in CANCELs so it doesn't need
to precede CANCEL processing either. If my hypotheses are correct,
Right. I'm guessing the via-branch parameter is only necessary for parallel
forking, right? In my case, I do serial forking only so offer is run for every
branch and then a delete is run for every failure...
--
You are receiving this because you are subscribed to this thread.
Reply to this
### Description
When called from within an event_route[tm:branch-failure:id],
rtpengine_manage() will do an offer instead of a delete, resulting in
duplicated sdp lines in body. Is this an omission or is it intentional?
### Troubleshooting
Reproduction
```
This is in the documentation section of sample kamailio.cfg, line 82. The
configuration section itself seems correct.
On Mon, 27 Jan 2020 at 20:07, George Diamantopoulos <
notificati...@github.com> wrote:
> Is there such a thing as route[JSONRPC]? Shouldn't this be
> event_route[x
Is there such a thing as route[JSONRPC]? Shouldn't this be
event_route[xhttp:request] instead?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I looked a bit and dst uri is not saved directly in the transaction branch
> structure, so there needs to be a larger patch involved to add this
> enhancement.
Is this fact the reason why $du does not hold the last used value in subsequent
runs of the branch_failure_route? Example:
```
The db_redis module seems to only support connecting with a single redis
instance. It is not evident from the documentation if it implements support for
native redis cluster by honouring 'MOVED' replies.
ndb_redis seems to have support for native redis clusters, and supports both
automatic
So are we not gathering at the K building this year? Going directly to the
restaurant?
On Mon, 28 Jan 2019, 08:33 Daniel-Constantin Mierla Forgot to mention the time: at 19:00, on Saturday, the 2nd of February.
>
> Cheers,
> Daniel
>
> On 28.01.19 08:29, Daniel-Constantin Mierla wrote:
> >
Thanks for the reply. I mostly opened this issue for tracking, and to
investigate if a potential fix is trivial or requires substantial work.
We are currently considering the alternatives, that is either wait for 5.2 and
use event_route to skip topos processing for subscribes, or deploy a
### Description
Kamailio seems to fail to properly route in-dialog SUBSCRIBE with the topos
module enabled. In this configuration, SUBSCRIBEs are expected to be delivered
to a downstream UAS, an asterisk instance in the internal network.
record_route() is executed for all initial requests,
Hello all,
It seems there has been a regression between kamailio 5.1.0 and 5.1.1 with the
topos module.
### Description
Kamailio acts as a proxy for asterisk instances residing in a private IP range
and other entities (subscribers, peers) residing on other networks. This is a
multihomed
You're right. I never would have thought that record_route() is somehow needed
for non-dialog-forming requests...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't have this issue with re-INVITEs, only with the 200 OK to OPTIONS.
Just as an update, this also happens with 5.1.0-stable.
Does your reINVITE issue go away if you disable topos entirely?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
io.cfg? That piece of code is new in
> 5.1, but executed only when debug is at least 3 (which is for
> troubleshooting purposes, not for production). Anyhow, I will check a bit
> that part to see if anything is wrong there...
>
> Cheers,
> Daniel
>
> On 30.11.17 18:52, George
I'm attaching the requested logs, hope it helps...
I've grepped the syslog with the call-id for the options message, I hope it is
sufficient.
[missing-via-topos-options.txt](https://github.com/kamailio/kamailio/files/1533559/missing-via-topos-options.txt)
--
You are receiving this because
Hello all,
I've come across the following issue with topos on Kamailio 5.1.0-rc2.
### Description
Kamailio acts as a proxy for asterisk instances residing in a private IP range.
Asterisk's peers are configured with their public IP address or hostname, but
asterisk will dispatch requests to
for
rtpengine)...
On 30 November 2017 at 01:08, George Diamantopoulos <georged...@gmail.com>
wrote:
> Oh, I also tried with 5.2.0-dev1 nightly and it also crashes in the same
> way...
>
> On 30 November 2017 at 01:07, George Diamantopoulos <georged...@gmail.com>
> wrote:
>
>
Oh, I also tried with 5.2.0-dev1 nightly and it also crashes in the same
way...
On 30 November 2017 at 01:07, George Diamantopoulos <georged...@gmail.com>
wrote:
> I've been trying to get a core dump on this for hours now, but I just
> can't get one! Is there anything sp
directory set in command line and in config file, I just can't get a core
dump...
Thanks
On 29 November 2017 at 18:10, George Diamantopoulos <georged...@gmail.com>
wrote:
> Hello,
>
> I've just installed kamailio 5.1 nightly from the debian repo for stretch.
> I didn
Hello,
I've just installed kamailio 5.1 nightly from the debian repo for stretch.
I didn't change anything in the configuration compared to 5.0.4 (which I
was testing previously), apart from the database structure as found in the
wiki for upgrading from 5.0.x.
Now kamailio crashes after a while,
46 matches
Mail list logo
