### Description
In my use case exists 1. pool of front-end proxies (all share some IPv4 address via AWS network load-balancer); 2. pool of backend registrars.
I must: 1. send keepalive messages to endpoints when used INVITE, REGISTRAR, SUBSCRIBE methods via all possible transports (UDP/TSP/TLS/WS/WSS/SCTP) (like nat_keepalive function of nat_traversal module). Internally store record for this SIP URI with flag `ka_dynamic` and `Record-Route` headers from `180, 183, 200` responses as `Route`; 2. send keepalive messages on predefined SIP URI (like ka_add_destination of keepalive module). Internally store record for this SIP URI with flag `ka_static` and manually defined `Route` value; 3. when keepalive for cases above is failed, then added record into arrays: a. ka_invite_failed; b. ka_registrar_failed; c. ka_supscribe_failed; d. ka_invite_succcess; e. ka_registrar_success; f. ka_supscribe_success; 4. need to trigger `even route` function with initialized `xavp` params of a. of SIP URI endpoints; b. relevant array ID; c. dynamic or static flag of SIP URI record; d. `Record-Route` of SIP URI record; 5.If we have arrays for multiple arrays, then the `event router` function called multiple times. 6. the time period for `event route` calls must be configurable via module settings; 7. when executed `event route` I want to have abbility a. send a new registration message to the registrar node using saved `Route` header when OPTION is successful for the statically defined SIP URI; a. send registration expiration message to the registrar node from received `200` response; b. send the clear subscription message to the node from received `200` response;
#### Actual observed behavior In current implementation `OPTIONS` keepalive messages send from different modules 1. usrloc; 2. keepalive; 3. nat_traversal; 4. nathelper
All the above have limitations like: 1. no TCP/TLS/WS/WSS transport support (nat_traversal, nathelper); 2. no ability to define call `event-route` on failed (success) OPTIONS message (think all modules do not have such feature); 3. no ability to check response code before enabling keepalive (nat_traversal); 4. no ability to notify backend REGISTRAR/SUBSCRIPTION server (think all modules do not have such feature) about failed keepalive messages;
#### What is expected
From my of view required:
1. some refactor of keepalive feature; 2. merge code from different modules into one and make other modules dependent; 3. implement the ability to notify backend REGISTRAR/SUBSCRIPTION servers of failed keepalive messages; 4. implement the ability to emulate registration when OPTION message success to SIP URI. Required on SBC to emulate customer PBX registration.
The modules like usrloc, nathelper and nat_traversal implemented the keepalive mechanism to solve specific needs (e.g., nat traversal pinhole punching or round trip time) mainly focusing on performance/scalability. They can be extended over the time, but I expect the focus will be still on scalability.
The keepalive is the generic module among them and, imo, sounds to be the place to add more complex/flexible keepalive features.
On the other hand, this request for features is more like technical requirements to build a product for your specific needs. If you added here because you want to develop such extensions and want to have a discussion or track its evolution, then all is fine. Otherwise, If you expect other developers to do it, I doubt anyone will engage her/himself on such task, unless they have the same needs.
The typical feature request should be around SIP specification (e.g., implement that RFC or parts of some RFCs), make configurable some existing values (e.g., switch an internal define to a parameter) or add some well defined component that is related to a popular system (e.g., mysql connector).
Therefore, unless you engage on doing this features request or other developers want take over it soon, I expect this to be closed in the near future.
Thanks, Daniel.
This ticket is made only for training needs. There can be discussions with other community members if they have similar needs. And you can close it at any time.
If you want to discuss with user community members, then it is better to use sr-users mailing list. If you want with developers, then sr-dev mailing list can be also a good place for discussions.
Ok. Will close ticket here
Closed #2565.