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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

firewall@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users