Klaus Darilion klaus.mailinglists@pernau.at writes:
Jens Thiele schrieb:
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
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.
- Path may disclose information you do not want to forward
(internal network address)
- You probably don't want to forward arbitrary SIP packets into
your internal network
of course you should some message screening on the openser before forwarding it to the registrar.
Well yes. The hard part here is that one may not have enough information to do "the right thing" at that point.
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.
Well - I guess the "depending on your security requirements" is the key point.
ack
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.
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.
Hmm maybe/yes.
Perhaps another solution would be something like a preliminary registration?
1) REGISTER crosses openser, openser does a save but notes: not yet acknowledged by upstream registrar.
2) if a sucessful reply from the upstream registrar is received, it notes: acknowledged.
3) if an INVITE comes in, only acknowledged registrations are used
But probably will get quite complicated, too? (bad guy can easily fill your usrloc with not yet acknowledged entries ...)
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.
Consider the following sequence: 1) User A registers sucessfully. openser usrloc and upstream usrloc are in sync. 2) User B fakes user A registration. upstream says no - but openser already saved => usrlocs are out of sync 3) call from outside which should get to A will go to B (and B might forward to A, staying in the middle of course)
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)
Sorry, I didn't want to say that you said it is easy. It is just when I tried it, I somehow got the impression it would be easy and I want to make sure people know that it is not.
I am still not convinced that it is doable if security matters but otherwise I think we agree. (of course I would still prefer if anybody would come up with a simple solution)
I also did take a look at milkfish some time ago and the config was really buggy.
ok (so its not me ;-)
Thanks, Jens