[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"

Hi, I'd like to comment some ideas I've read in:

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

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

Users mailing list
[hidden email]