-
Notifications
You must be signed in to change notification settings - Fork 118
pkg/sip/outbound.go: allow overwriting autogenerated SIP headers with ones suppiled by the user #518
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
base: main
Are you sure you want to change the base?
Conversation
… ones suppiled by the user
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #518 +/- ##
==========================================
- Coverage 65.25% 64.36% -0.89%
==========================================
Files 51 32 -19
Lines 6588 6076 -512
==========================================
- Hits 4299 3911 -388
+ Misses 1915 1771 -144
- Partials 374 394 +20 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
dennwc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, but we cannot allow changing a few core headers in our SIP deployments. This should either be an optional flag or a custom patch in your fork. Otherwise it may interfere with routing and we won't be able to provide any support for it.
Having said that, we are open for discussions if you want to be able to control specific parts of the From header. For example, recently we exposed an option for setting a display name for the From URI. Is there something specific you want to configure there?
|
@dennwc Thanks for the direct reply! A patch in our fork is what we obviously have but if i get it correctly, we cannot use LiveKit cloud with a local livekip-sip component, right? How would you imagine this "optional flag" variant to be implemented? A flag in sipOutboundConfig that enables header overwriting or a second set of (unsupported) header modifications being passed down? We'd be happy to implement it :) In our specific case, the PBX expects the From Header Address to be From our experience with hundreds of quirky implementations and thousands of quirky setups of SIP out there, we'd suggest that a general "customize everything and be unsupported, because you know what you are doing"-solution would be preferable over adding more and more options trying to reach compatibility for specific details and situations. :) |
That's correct. We could enable it for inbound pretty quickly, but the outbound part will require a more significant work on our side.
I was assuming you want this in OSS, in which case it would be in the SIP config file. But for Cloud, we just cannot add it, since that assumes a certain level of support.
You may have noticed that if you put There's nothing forcing you to use an IP instead of FQDN and nothing preventing you from putting some extension number in the number field. If that's all you need - it's possible in Cloud right now.
Sure, for OSS that's what we are trying to do. But for the Cloud, we might be a bit more opinionated than that 🙂 |
|
Partially understanding your opinion on the cloud, although it will force us out of using it.
Not completely sure what you mean, maybe i'm blind at the moment... We're not aware how to influence the |
|
Ah, okay, I see now. I assume you do not own that FQDN, right? Cloud does support custom domain names for SIP and will populate From based on it. |
|
No, we do not own |
We're trying to figure out how to use a "custom domain name" in LiveKit cloud but we cannot find any options or docs for it. Can you give us a hint? |
please contact me at dz at livekit dot io. this is an enterprise feature that we've enabled for some customers |
This allows users to override generated SIP headers and enables to achieve custom compatibility with a wide range of SIP-Servers/PBX-Systems.
For us this is a blocker for using LiveKit Cloud because it does not work with our existing telephony infrastructure.
Running livekip/sip locally with this change, we are able to place calls with our proprietary PBX system by constructing the From header ourselves.