17 Apr
2008
17 Apr
'08
7:31 p.m.
Jens Thiele schrieb:
Well - I guess the "depending on your security requirements" is the key
point.
Wouldn't it be possible to save needed parameters during request
processing in AVPs and during 200 response processing save the AVPs
using raw DB queries. I think in single-domain setups it is doable.
Of course it would be nicer to modify save() to work on responses too.
Klaus Darilion <klaus.mailinglists(a)pernau.at>
writes:
of course you should some message screening on the openser before
forwarding it to the registrar.
Gentrice's kaiser schrieb:
1. Path may disclose information you do not want to forward (internal
network address)
2. You probably don't want to forward arbitrary SIP packets into your
internal network Hi,
The hard part is upper register . It means user auth information is
stored in Broadsoft instead of your mysql DB.
If broadsoft supports
"Path" then it should be easy by forwarding the
REGISTER to broadsoft and adding a Path header. Further, save() (before
or after forwarding) for NAT pinging. If Path is not supported then it is more
complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite
likely, then it is much more complicated and at the moment, depending on
your security requirements, not doable without modifying openser code. You have to
save() the original contact and the public socket of the
client. Further you have to rewrite the contact header before
forwarding, so that the URI points to openser. Further, you have to put
some identifier into the user part which will then be used to lookup the
usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on
successful replies to a register and that IMHO is not possible. Otherwise any client in your network may populate your
usrlow without
credentials and depending on your setup just grab other users accounts.
Even if you save() during request processing and have "bad" data in the
usrloc table account hijacking shouldn't be possible because if the
registration fails on the registrar, the registrar wont forward incoming
calls to openser.
But once more: please correct me - post some example
config.
My point is: I wasted a lot of time with that and I think it is really
bad to make people believe this is easily doable.
I didn't said "easily doable". But I remember I made such an
outboundproxy based on openser using a rather old openser version just
by using tons of regular expressions and massive message rewriting. Thus
I think it is doable (but not easily)
I ended up using asterisk for this.
Greetings
Jens
PS: the closest match I did find is milkfish [1] which has IMHO the problem
described above.
http://www.milkfish.org/
http://packages.milkfish.org/boozy/Milkfish_Sources_for_OpenWrt-SDK/OpenWrt…
I also did take a look at milkfish some time ago and the config was
really buggy.
regards
klaus