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

[Richard Revels]

I didn't really have any plans to comment on the wish list being  
created as everyone has their own needs.  However, since you went  
there first, here is what I believe about XML.

I don't think there is a valid reason to ever have a file on disk that  
contains XML formatted data.  XML was thought up to provide a means  
for the Porno sites to make direct transfers of credit transactions  
from their DOS based computers to the bank mainframes without dropping  
any decimals.  Since that time, no valid use has ever been found for it.

If XML is going to be used, for the transfer of data from one computer  
system to another, it should be generated on the fly and ungenerated  
before saving on the far side.  I should never be forced to view XML  
formatted data.

Richard

On Nov 26, 2008, at 9:21 PM, 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). 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.
>
> 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.
>
>
>
> 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?
>
>
> ------------------
> - 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"...
>
>
> ------------------
> - 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?
> Also there are cool functions in OpenSIPS modules, for
> example "loose_route()". Would you imagine implementing that funcion  
> in
> each "possible" high level language?
>
>
> ------------------
> - Replace current scripting with XML
> -------------------
>
> Ahhhhhhhhhhhhhhhhhhh !!!!!!!!!
>
>
>
>
> Just my 2 cents, opinions? Regards.
>
>
>
> -- 
> Iñaki Baz Castillo
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users