miconda left a comment (kamailio/kamailio#4236)
I haven't implemented that matching mode and it was a bit weird from the
beginning (weight of matching socket is higher than port+proto), anyhow, what
you commented seemed valid, the continue statements were preventing the setting
of a matching no
miconda left a comment (kamailio/kamailio#4280)
I think it is better so, more flexible via function param.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4280#issuecomment-2963734291
You are receiving this because you are subscribed to this thread
henningw left a comment (kamailio/kamailio#4281)
Thanks for the report. I have some pending changes related to randomness in
other areas as well, let me have a look to it.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4281#issuecomment-2963489
Module: kamailio
Branch: master
Commit: dfb5ef6f9d670a9ee2de223eac0a665f9e5cab71
URL:
https://github.com/kamailio/kamailio/commit/dfb5ef6f9d670a9ee2de223eac0a665f9e5cab71
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2025-06-11T19:56:57+02:00
dispatcher: rename var
ChristianBergerSipgate created an issue (kamailio/kamailio#4281)
### Description
The rtpengine module uses a `cookie` field in the Protocol controlling
rtpengines. This field needs to be unique, and is derived from the `server_id`
field set in the Kamailio, the `pid` as well as the value of a v
henningw left a comment (kamailio/kamailio#4250)
> @henningw no, as @miconda mentions.
>
> > The ACKs for 200ok are end-to-end, should not be generated by Kamailio,
> > just forwarded (stateless). But the ACKs for 300+ replies of
> > received+relayed INVITEs are hop-by-hop, and they should not
tsearle left a comment (kamailio/kamailio#4250)
@henningw no, as @miconda mentions.
> The ACKs for 200ok are end-to-end, should not be generated by Kamailio, just
> forwarded (stateless). But the ACKs for 300+ replies of received+relayed
> INVITEs are hop-by-hop, and they should not trigger b
tsearle left a comment (kamailio/kamailio#4250)
@henningw Correct, only 2xx OK to Generated INVITE will have an ACK in the
local request. I tested the 2xx case, @xkaraman tested the non-2xx case, I am
not sure if he retested with a 2xx case.
--
Reply to this email directly or view it on GitHu
henningw left a comment (kamailio/kamailio#4250)
> @henningw Correct, only 2xx OK to Generated INVITE will have an ACK in the
> local request. I tested the 2xx case, @xkaraman tested the non-2xx case, I am
> not sure if he retested with a 2xx case.
Thanks for the feedback. But it should trigger
henningw left a comment (kamailio/kamailio#4250)
It got a bit confusing for me, so I tried to summarize the different cases:
1. INVITE between phones A-Proxy-B, no ACK logging in local request event
route for 200 OK and non 200 OK
This seems to be working as expected with the PR according to
furmur left a comment (kamailio/kamailio#4280)
changed to use new _vmode_ value in `loose_route_mode(vmode)` instead of the
`force_lr_no_outbound_flag` param
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4280#issuecomment-2962612683
You are rece