[OpenSER-Users] kagoor voiceflow replacement

[Jens Thiele]

Klaus Darilion <klaus.mailinglists at pernau.at> writes:

> Jens Thiele schrieb:
>> Klaus Darilion <klaus.mailinglists at 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.
>>  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
>
> 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