[sr-dev] Re: [kamailio/kamailio] extented haproxy protocol support (PR #3731)

This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3731#issuecomment-2196008221 You are receiving this because you are

[sr-dev] Re: [kamailio/kamailio] ims_registrar_scscf: cannot build on Fedora 40 (Issue #3855)

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3855#issuecomment-2196008252 You are receiving this because yo

[sr-dev] Re: [kamailio/kamailio] Wrong Route header order in called party re-INVITE when using topos (Issue #3778)

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3778#issuecomment-2196008236 You are receiving this because yo

[sr-dev] Re: [kamailio/kamailio] The RPC `rtpengine.show` API result has the field `disabled` type change on different values. (Issue #3896)

Then how about: - `disabled`: `boolean` - set to `true` if the RTPEngine was disabled by an RPC call - `active`: `boolean` - set to `true` if the module is actively using this RTPEngine (i.e. the internal `rn_disabled` flag is set to 0). This will be always set to `false` if `disabled` is set to

[sr-dev] Re: [kamailio/kamailio] The RPC `rtpengine.show` API result has the field `disabled` type change on different values. (Issue #3896)

FWIW this is legacy from when the RPC code was converted from the old mi interface to the new one. Looks like `recheck_ticks` is also affected by this. If you feel like taking a stab at improving then, feel free. I don't mind a patch that changes the output to something more sensible (although i

[sr-dev] Re: [kamailio/kamailio] ims_registrar_pcscf: support for handling contact * value (Issue #3848)

Errm... I think we would need a fix first :wink: ... @miconda hinted that patches would be welcomed. So to spell it out: please contribute. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3848#issuecomment-2194744104 You are receiving this becau

[sr-dev] Re: [kamailio/kamailio] ims_registrar_pcscf: support for handling contact * value (Issue #3848)

I can help in this regard. Kindly let me know when to test. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3848#issuecomment-2194730449 You are receiving this because you are subscribed to this thread. Message ID: ___

[sr-dev] Re: [kamailio/kamailio] ims_registrar_pcscf: support for handling contact * value (Issue #3848)

I agree with @deepak-git-account and in general that IETF RFC functionality should be implemented also for IMS domain. And it would be good if the P-CSCF registrar would delete all Contacts locally. But... things are a bit more complex. 3GPP TS 24.229 does specify a behavior of "*" Contact, yet

[sr-dev] [kamailio/kamailio] ims_registrar_scscf: fix for location AOR with empty host (PR #3897)