-
Notifications
You must be signed in to change notification settings - Fork 581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] uac_registrant match URI to Contact header partially #2557
Comments
Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days. |
@vasilevalex , IMHO, the |
oh, hold you, by contact matching you mean identifying its own contact from the list of returned contacts, right ? |
@bogdan-iancu Yes, it's about matching contact from "200 OK" reply. And now it is done by strict comparing with value of binding_URI column. And it's not flexible at all. But PR is not perfect, because I just took existing |
OK, I see it. Maybe we can solve this (somehow) by using the recent "tag" of the interfaces. So, in the uac_registrant binding URI you use the "tag" of the interface and we need to trick the matching function to use it , when comparing the host part of the URI......just a rough, superficial idea :) |
If the host has active "tag" for the registration entry, it can generate Contact header with hostname or ip-address, belonging to this host. That part I did in config script in |
@vasilevalex , checking the module I see that the |
Hi @bogdan-iancu,
and
binding_URI is mandatory parameter. And if it's empty the record is just skipped.But even if it would be automatically generated, forced_socket is perfect for use, but what to do with "user" part of URI? It is usually phone number, as we want to receive calls to the numbers. But in real life registration data (username) and contact header URI (username) are different, so anyway we need to have some unique "user" part of URI to create final "binding URI".
I have setup with my patch in production for many months. But as you said before, the right way is to use active tag for every record to generate URI, when sending outgoing registration. And it of course can be conditional (another module parameter) to keep compatibility. |
Is your feature request related to a problem? Please describe.
If we have a lot of external registrations, let's say 100000, we can distribute them through several, for example 10 servers. Put accounts to the DB, connect all OpenSIPS servers to this DB, create cluster of servers.Create for example 10 different tags for cluster, so each server will process only 10% of total amount of registrations. And if one server dies, just move its' tag to another server. It will increase load twice, but everything will be reliable.
Very simple scheme. Just every server substitutes its' IP-address instead of the hostname in "binding_URI" when sending outgoing REGISTER:
Everything works, except one problem. Expiration time for registration, provided in "200 OK" from external system is not applied to OpenSIPS. Because module uac_registrant compares URI from Contact header from "200 OK" to the full value of "binding_URI". They are different, as we are changing Contact in outgoing REGISTER.
It would be nice to have parameter for matching contact URI, to choose what parts of URI must match. And just ignore the rest.
Describe the solution you'd like
Parameter to uac_registrant module to choose what parts of URI use to match.
Implementation
I'll send PR
Describe alternatives you've considered
Store in
reg_record->contact
not just raw value ofbinding_URI
, but dynamic value with host depending on sending socket.The text was updated successfully, but these errors were encountered: