I do not see benefits of the variant you propose, there must be conditions to figure outing tenants, which direction is going to be, how to route it, etc...
But you can add new functions as you consider useful, there is also a function for record route with advertised address.
Cheers, Daniel
On 11.02.21 17:02, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The record_route_preset() is supposed to offer the flexibility of setting the address part in RR headers via variables. I do not see how the record_route() can be better variant, because it will end up in the same kind functionality: for which to use the FQDN? For first of the second Record-Route header, or for both?
I was thinking this kind of new function:
record_route_with_fqdn(first_header_fqdn, second_header_fqdn)
It would work the same way as record_route, but would use the fqdn param instead of IP address if the param is not "".
So, when INVITE goes to teams, I would make call
record_route_with_fqdn("tenantX.teams.tutpro.com", "");
and then INVITE comes from teams, I would make call
record_route_with_fqdn("", "tenantX.teams.tutpro.com");
These are conditions that are made in configuration file, based on routing needs, when deciding what socket to use and where to send. There are variables that give access to receiving socket ip/port or sending socket.
Yes, I know that the variables exist, but it is messy to use them.
-- Juha