Hi Community,
Is it a common experience for architects to encounter issues with active/active registrar designs? Specifically, when clients are the UAS of a dialog? Some user agents accept INVITEs from any source once registered while others are not as accepting.
There are ways around this using 302 redirect, but there seem to also be ways per RFC to signal trusted nodes to clients. RFC 3608 seems to be an excellent way to address this issue by communicating trustworthy nodes to the client upon registration. However, the Service-Route header seems to give options to the client rather than communicate trust.
No where in the RFC does trust seem to be mentioned in its design, however one could imply it should be deduced by the presence of a Service-Route header.
Nonetheless, even if it should communicate trust, it doesn't seem to do so in all cases so the more logical approach to active/active is signal via a 302 redirect where the registration lives, handling INVITE transactions on the server-side instead of client-side.
I'm curious to hear if there is any advice on from the community overcoming trust issues with user agents in an active/active registrar design.
It is common, and there's no single or perfect solution. A lot of the answers are device and network-specific
SIP Outbound (RFC 5626) is, I think, the officially sanctioned remedy, but, while Kamailio supports it, most customer equipment in the field to date, as far as I know, does not.
-- Alex
On Sep 20, 2024, at 11:46 AM, Knserbrave via sr-users sr-users@lists.kamailio.org wrote:
Hi Community,
Is it a common experience for architects to encounter issues with active/active registrar designs? Specifically, when clients are the UAS of a dialog? Some user agents accept INVITEs from any source once registered while others are not as accepting.
There are ways around this using 302 redirect, but there seem to also be ways per RFC to signal trusted nodes to clients. RFC 3608 seems to be an excellent way to address this issue by communicating trustworthy nodes to the client upon registration. However, the Service-Route header seems to give options to the client rather than communicate trust.
No where in the RFC does trust seem to be mentioned in its design, however one could imply it should be deduced by the presence of a Service-Route header.
Nonetheless, even if it should communicate trust, it doesn't seem to do so in all cases so the more logical approach to active/active is signal via a 302 redirect where the registration lives, handling INVITE transactions on the server-side instead of client-side.
I'm curious to hear if there is any advice on from the community overcoming trust issues with user agents in an active/active registrar design. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Alex Balashov via sr-users writes:
SIP Outbound (RFC 5626) is, I think, the officially sanctioned remedy, but, while Kamailio supports it, most customer equipment in the field to date, as far as I know, does not.
Yes, that is the best solution. SIP UA registers via two outbound proxies and is thus able to receive INVITEs from both. There are SIP UAs that support it.
-- Juha
Thank you this definitely looks like what I am after.
On Fri, Sep 20, 2024 at 2:05 PM Juha Heinanen via sr-users < sr-users@lists.kamailio.org> wrote:
Alex Balashov via sr-users writes:
SIP Outbound (RFC 5626) is, I think, the officially sanctioned remedy, but, while Kamailio supports it, most customer equipment in the field to date, as far as I know, does not.
Yes, that is the best solution. SIP UA registers via two outbound proxies and is thus able to receive INVITEs from both. There are SIP UAs that support it.
-- Juha __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Alex Balashov -
Juha Heinanen -
Knserbrave