El Jueves, 27 de Noviembre de 2008, Dan Pascu escribió: > > Well, while it seems good, I consider it impossible (unfortunatelly). > > Fortunately, history shows us that progress was done by people who didn't > knew that something was impossible, so they tried anyway :P
Sure something can be improved, but what I meant is that it's not so easy to separates layers when dealing with NAT issues. > > Sincerelly I consider unfeasible a cool separation between low level > > and high level functionalities. SIP, NAT and company is too complex to > > allow an "easy" configuration splitted in abstract layers. > > So you suggest we should just stop here, close the lights and go home? Of course no! I just wanted to say my opinion about some suggestions, just to open a debate. Hopefully I'm completely wrong and this kind of layer separation is fully feasible ;) > > ------------------ > > - no special scripting skills will be required (as using common known > > languages) > > ------------------ > > > > ¿?¿? If you need to match a regular expression you need "some" > > scripting skills. The same if you need to do a "case", "if"... > > You missed the point. It's about not needing to learn yet another > scripting language with all its severe limitations (i.e. opensips.cfg) Yes, I missed the point, thanks for clarification. > > ------------------ > > - using existing languages, the scripting become more powerful as it > > has access to all libs for DB, variables, arrays, string ops, etc. > > ------------------ > > > > How would be the performance if OpenSIPS must run PHP/Python/Ruby code > > for each message? > > I'm sick and tired of people being performance experts without running a > single benchmark, just based on assumptions and common myths. Not to > mention that in this case it's even more silly as there was no design > presented yet, just some requirements. So you have no idea how things > will be, but you can already make absolute claims about the performance > of the system... I rest my case. Dan, if you re-read my phrase you will realize that *it was just a question*, I'm not doing assumpions. > > Also there are cool functions in OpenSIPS modules, for > > example "loose_route()". Would you imagine implementing that funcion in > > each "possible" high level language? > > Where did you read that loose routing will be performed by the application > layer? > And BTW, loose_route is not a cool function. It's an oxymoron. Something > that should be done automatically and you should never even need to know > about. Imagine you run the "presence" module in the same box as the proxy. Then you do need some logic in your in-dialog section (but not into "loose_route" section since in-dialog SUBSCRIBE/PUBLISH will have no Route header pointing to our proxy). I think this is a mix between application/routing/core layer, is not? Again: I could be perfectly wrong :) > That page is just a wishlist. Of course, I'm just commenting it. ;) -- Iñaki Baz Castillo _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
