[OpenSIPS-Users] [Copfilter] Copy of quarantined email - About OpenSIP "The New Design"

[firewall at olli.ath.cx]

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