Closed #1757.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1757#event-2034980783___
Kamailio (SER) - Development Mailing List
sr-dev@l
Thank you, has been merged into git master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1757#issuecomment-448504504___
Kamailio (SER)
@teotwaki I will also look to your code today or latest tomorrow morning and
give you feedback.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1757#issuecomment-447240867_
I was expecting to have the proxy's public address and port. I understand this
might have side effects, and that's exactly what I wanted to test.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/ka
What would you want to have in `$Ri` and `$Rp`? They have to refer to a local
socket, otherwise it may have unexpected side effects for other components.
It should be at least different commits for each major component it changes.
You can make it with more commits, it can be squashed from PR web
I seem to have made some good progress:
```
10(20) INFO: {1 1 INVITE 6f350846ab60b1d60295d17268df1605@0.0.0.0}
@teotwaki - is the PROXY header sent in clear, before establishing the tls
connection? If yes, then do it after accept.
Regarding the patch referenced above, I haven't looked extensively at the code
parsing the proxy header, but adding the new parameter looks good.
--
You are receiving this be
@miconda & @henningw: Could I ask for some early input on my current progress?
https://github.com/kamailio/kamailio/compare/master...teotwaki:sl/implement-proxy-protocol
One thing that occurred to me, is that this parsing has to be done at a
different moment than what we do with HEP3. From what
@teotwaki - following the hep3 handling should be a good approach, thanks for
considering to contribute and working on this feature!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues
Your idea sounds interesting, and I can see a benefit as well especially for
the mentioned use cases (AWS and haproxy setups). Daniel has probably also some
comments on this, but in my opinion your approach sounds reasonable.
* Add a core variable, e.g. ksr_tcp_accept_proxy
* add a functio
@miconda I would mainly love some pointers as to how/where to implement this.
My initial thought was to modify `handle_new_connect()` to change the
connection state to `S_CONN_OK` instead of `S_CONN_ACCEPT`, and then peek the
connection to see if we are getting a PROXY v1/v2 header, and the over
### Description
I would like to implement support for the Proxy Protocol as implemented by
HAProxy and AWS ELBs. The main advantage this brings is better connection
information, even behind multiple layers of NAT or LBs. This feature was
already discussed a couple of years ago, and it appears t
12 matches
Mail list logo
