[OpenSIPS-Devel] [OpenSIPS-Users] About OpenSIP "The New Design"

[Dan Pascu]

On Thursday 27 November 2008, Iñaki Baz Castillo wrote:
> Hi, I'd like to comment some ideas I've read in:
>   http://www.opensips.org/index.php?n=Development.NewDesign
>
> -----------------------------------
> 2.2  Application Layer
> - separation between low level functionalities (transport,
> registration, SIP, NAT, rr+loose_route, TM, dialog, presence, etc) and
> high level functionalities (routing, authentication, accounting,
> checks, DB, LDAP, snmp, etc)
> - this will allow easy creation of the high-level functionalities
> without getting into low level things: if I do a routing functionality,
> why should I care about NAT traversal?? -> reduces the script
> complexity as it will focus mainly on service creation, rather on
> making SIP to work)
> -------------------------------------
>
> 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

> Imagine the following case (it's a real case):
>
> - Two gateways to deliver/receive calls to/from PTSN: gw_A and gw_B.
> - gw_A allows Comedia mode (no STUN or RTP proxy required).
> - I just want to use RTP proty when routing calls to gw_B (needed).
> - So handling with NAT depends directly on routing basis.
>
> Other example (also real):
>
> - Local users alice and bob registered behind the same NAT router (same
> public IP) with no STUN configured.
> - alice calls bob, the proxy detects that both are behind same NAT
> router so allow direct RTP (no use of RTP proxy).
> - Now bob also registers from a device with public IP.
> - alice calls bob again (parallel forking now).
> - The branch with public IP needs RTP proxy since alice is behind NAT.
> - So handling NAT depends directly on each branch routing.

I see no problem with either of your examples. NAT decisions are taken in 
the application, not the core. Same for branching.

> 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?

> I also read:
>
> ------------------
> 2.1  Scripting
>
> - replace the custom scripting language with existing high level
> programing languages (perl, php, python, JAVA, etc)
> - more than one type of language to be used
> ------------------
>
> Really? can you imagin debugging a OpenSIPS script written in *any*
> language?

Actually I really can. There are debuggers for various languages, unlike 
the current script opensips uses, which can only be debugged with the 
Poor Man's Debugger TM (i.e. prints)

> ------------------
> - 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)

> ------------------
> - 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.

> 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? Where did you read anything about how things will work anyway? 
That page is just a wishlist.

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.

-- 
Dan