Skip to content
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

Preserve To field #3

Open
SilvaMendes opened this issue Sep 30, 2024 · 3 comments
Open

Preserve To field #3

SilvaMendes opened this issue Sep 30, 2024 · 3 comments
Labels
breaking change enhancement New feature or request good first issue Good for newcomers

Comments

@SilvaMendes
Copy link

Hello, I would like to suggest adding it to diego.go, to preserve the To field, in situations where a b2b receives the request from a different domain but the To realm is different.
example:
Change_From_To

@emiago
Copy link
Owner

emiago commented Sep 30, 2024

Hi @SilvaMendes thanks for reporting. This could be yes and no. I guess this needs to be proven more is it worth. I think this is not even default behavior for asterisk. (Correct me if I am wrong).

Still passing custom headers is possible (yes content type and from is added always). So you can pass your own (TO header)

Anyway I would like to see some reference todo this change. I know cases where you do not want to share your internal domains or just letting endpoint to accept requested domain.

@SilvaMendes
Copy link
Author

SilvaMendes commented Oct 1, 2024

Hello @emiago , it is common to use the to field with a realm different from the ruri, in opensips we work with multi-domain from To, considering that the request can come from a CNAME type bind.
ex: https://opensips.org/docs/modules/3.4.x/uac.html#func_uac_replace_from

@emiago
Copy link
Owner

emiago commented Oct 1, 2024

Hi @SilvaMendes so we are probably speaking some multi tenant setup. So yes I could see here some sense to have that default.
Yeah per RFC nothing is wrong here, just I want to weight is this something should be default behavior. Like topology hidding.
Anyway I think I will accept this feedback, but I need to add more logic in order to increase flexiblity

@emiago emiago added enhancement New feature or request good first issue Good for newcomers labels Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants