### Description
When using the RPC command `rtpengine.show`, the resulting list has the field `disabled` for each RTPEngine configured, and its value - for some reason can be either `0` (number), `1` (number) or `"1(permanent)"` (string).
For example:
``` $ curl -k -X POST -HContent-Type:application/json -d '{"jsonrpc":"2.0","method":"rtpengine.show","params":["all"],"id":1}' https://localhost:8443/rpc { "jsonrpc": "2.0", "result": [{ "url": "udp:old-rtpengine2227", "set": 0, "index": 0, "weight": 1, "disabled": 1, "recheck_ticks": 0 }, { "url": "udp:172.24.73.28:2227", "set": 0, "index": 1, "weight": 1, "disabled": 0, "recheck_ticks": 0 }, { "url": "udp:172.24.75.15:2227", "set": 0, "index": 2, "weight": 1, "disabled": "1(permanent)", "recheck_ticks": "N/A" }], "id": 1 } ```
This makes it very annoying to parse the results from JSON RPC (and maybe other machine readable RPC APIs). Also the same problem for `recheck_ticks`, but I never actually read it so it is less important for me.
#### Reproduction
The difference between `0` and `"1(permanent)"` can be seen by setting up multiple RTPEngine sockets that work and then disable one of the using the `rtpengine.enable` RPC command with the `flag` set to `0`. As far as I can tell that is the only way to get `recheck_ticks` to be set to `RTPENGINE_MAX_RECHECK_TICKS` which causes the "permanently disabled" state.
### Possible Solutions
I can try to offer a patch, but any change I can make will be a breaking API change - so if users are relying on this weird behavior, that could be a problem.
Maybe the best way to move forward is to expose two additional fields:
- `active` : `boolean` - set to `true` if the RTPEngine is not disabled, and to `false` if it is disabled (i.e. the value is equal to `disabled == 0`). - `active` : `boolean` - set to `true` if the RTPEngine had not failed it checks (i.e. `recheck_ticks` is either 0 or `RTPENGINE_MAX_RECHECK_TICKS`). This will be set to `false` if `disabled` is set to `1`, and not `"1(permanent)"`.
Maybe the last field is unneeded? Maybe `"disabled"` can be changed to only report whether the RPC was used to disable the socket and let the `active` field specify whether the socket can be used?
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.7.5 (x86_64/linux) 58499a flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 58499a compiled on 00:00:00 Sep 13 2022 with gcc 11.4.1 ```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `lsb_release -a` and `uname -a`) -->
``` $ uname -a Linux sip-172-24-50-23.XX.XX.XX 6.5.0-1020-aws #20~22.04.1-Ubuntu SMP Wed May 1 16:10:50 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/os-release NAME="AlmaLinux" VERSION="9.4 (Seafoam Ocelot)" ID="almalinux" ID_LIKE="rhel centos fedora" VERSION_ID="9.4" PLATFORM_ID="platform:el9" PRETTY_NAME="AlmaLinux 9.4 (Seafoam Ocelot)" ANSI_COLOR="0;34" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos" HOME_URL="https://almalinux.org/" DOCUMENTATION_URL="https://wiki.almalinux.org/" BUG_REPORT_URL="https://bugs.almalinux.org/"
ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9" ALMALINUX_MANTISBT_PROJECT_VERSION="9.4" REDHAT_SUPPORT_PRODUCT="AlmaLinux" REDHAT_SUPPORT_PRODUCT_VERSION="9.4" SUPPORT_END=2032-06-01 ```