Re: [OpenSIPS-Users] About OpenSIP The New Design
On Thursday 11 December 2008, Jiri Kuthan wrote: Dan Pascu wrote: On Wednesday 10 December 2008, Jiri Kuthan wrote: Which of those are you exactly missing with SER? You are offtopic. This is an OpenSIPS mailing list. Please post your SER related questions to the SER mailing lists. Unfortunately performance as a reason was abused many times on the *SER mailing lists and has even led to bad design decisions. ^^^ So these bad design decisions (see the line above) are related to opensips? Nobody is really interested around here in your Mine is bigger, stupid! contests. Grow up. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
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 --- Ahhh ! Just my 2 cents, opinions? Regards. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
That page is publicly editable by anyone. It's purpose is to let people express ideas and wishes. We have no intention of stopping people from writing anything there as it is used for brainstorming. You can go there and say you want your kittens to transport SIP messages from house to house. That doesn't mean it will happen. On Thursday 27 November 2008, Richard Revels wrote: 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 --- Ahhh ! Just my 2 cents, opinions? Regards. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
On Thursday 27 November 2008, Iñaki Baz Castillo wrote: El Jueves, 27 de Noviembre de 2008, Dan Pascu escribió: 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 Sure something can be improved, but what I meant is that it's not so easy to separates layers when dealing with NAT issues. I'd say let's leave this debate for when we have a design blueprint in front of us. Otherwise we can speculate endlessly. 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. Dan, if you re-read my phrase you will realize that *it was just a question*, I'm not doing assumpions. I know it was a question, but my frustration related to the performance obsession on *SER lists has kicked in. Unfortunately performance as a reason was abused many times on the *SER mailing lists and has even led to bad design decisions. As I said many times, performance cannot be discussed without benchmarks and code profiling. And there are other things to consider as well along performance. There's a story that reflects what I think about how the performance argument was used many times in the *SER communities in the past: An absent-minded professor was getting late for a presentation he had to make. Realizing how late it was, he jumped into a taxi and yelled to the driver: Hurry up! Hurry up! Go as fast as your can!. While the cab was running like crazy through the city, the professor realized he didn't mention where he wanted to go. So he asked the driver: Do you know where you're going?. No sir said the driver, but I go as fast as I can! 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? 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. Imagine you run the presence module in the same box as the proxy. I can imagine many things ;), but as I said let's discuss on the design proposal when it becomes available. Then you do need some logic in your in-dialog section (but not into loose_route section since in-dialog SUBSCRIBE/PUBLISH will have no Route header pointing to our proxy). I think this is a mix between application/routing/core layer, is not? All I can tell you is that the new design we have in mind is so different from what you already know, that it's very difficult to make assumptions about it from what you already know from the old design. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
El Jueves, 27 de Noviembre de 2008, Dan Pascu escribió: 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 Sure something can be improved, but what I meant is that it's not so easy to separates layers when dealing with NAT issues. 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? Of course no! I just wanted to say my opinion about some suggestions, just to open a debate. Hopefully I'm completely wrong and this kind of layer separation is fully feasible ;) -- - 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) Yes, I missed the point, thanks for clarification. -- - 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. Dan, if you re-read my phrase you will realize that *it was just a question*, I'm not doing assumpions. 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? 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. Imagine you run the presence module in the same box as the proxy. Then you do need some logic in your in-dialog section (but not into loose_route section since in-dialog SUBSCRIBE/PUBLISH will have no Route header pointing to our proxy). I think this is a mix between application/routing/core layer, is not? Again: I could be perfectly wrong :) That page is just a wishlist. Of course, I'm just commenting it. ;) -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About OpenSIP The New Design
El Jueves, 27 de Noviembre de 2008, Dan Pascu escribió: All I can tell you is that the new design we have in mind is so different from what you already know, that it's very difficult to make assumptions about it from what you already know from the old design. Ok, let's wait for it ;) -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] About OpenSIP The New Design
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 --- Ahhh ! Just my 2 cents, opinions? Regards. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
