Re: [OpenSIPS-Devel] SF.net SVN: opensips:[7609] branches/1.6/scripts/mysql_update_1_6_4.sh
There is one more copy-paste bug for presence tables (acc instead of presentity): - run_query - Adding new 'extra_hdrs' field in PRESENTITY table ALTER TABLE acc ADD COLUMN extra_hdrs BLOB DEFAULT '' NOT NULL + run_query - Adding new 'extra_hdrs' field in PRESENTITY table ALTER TABLE presentity ADD COLUMN extra_hdrs BLOB DEFAULT '' NOT NULL Am 21.12.2010 13:43, schrieb Vlad Paiu: Revision: 7609 http://opensips.svn.sourceforge.net/opensips/?rev=7609view=rev Author: vladut-paiu Date: 2010-12-21 12:43:43 + (Tue, 21 Dec 2010) Log Message: --- Fixed bugs in mysql_update script Modified Paths: -- branches/1.6/scripts/mysql_update_1_6_4.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[7571] trunk/modules/rls
Anca, I noticed (1.6.4) that RLS does not terminate back-end subscriptions when the list subscription expires. Is there a reason for hat or is it just not implemented? regards klaus Am 20.12.2010 12:24, schrieb Anca Vamanu: Revision: 7571 http://opensips.svn.sourceforge.net/opensips/?rev=7571view=rev Author: anca_vamanu Date: 2010-12-20 11:24:38 + (Mon, 20 Dec 2010) Log Message: --- - fixed expires value notification at timeout(reported in bug #3140296) Modified Paths: -- trunk/modules/rls/rls.c trunk/modules/rls/subscribe.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[7571] trunk/modules/rls
Am 21.12.2010 18:05, schrieb Anca Vamanu: On 12/21/2010 06:22 PM, Klaus Darilion wrote: Anca, I noticed (1.6.4) that RLS does not terminate back-end subscriptions when the list subscription expires. Is there a reason for hat or is it just not implemented? I guess the reason was that the backend subscription should expire also as the expires values is the same. Except min_expires is set in pua module (README is wrong, default value is 300 and not 0) and larger than list subscription expiration. regards klaus ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5835] trunk/modules/pua_dialoginfo
Hi Anca! Nice feature, missing since long time :-) If I understand the code, this triggers PUBLISH with trying even if the dialog is not created (e.g. script error after dialoginfo_set()). In this case, it will stay in trying state for default lifetime. Wouldn't it be better to send trying also from a callback. regards klaus Anca Vamanu schrieb: Revision: 5835 http://opensips.svn.sourceforge.net/opensips/?rev=5835view=rev Author: anca_vamanu Date: 2009-07-06 16:06:57 + (Mon, 06 Jul 2009) Log Message: --- - changed the was dialoginfo publications are triggered. Now for triggering dialoginfo publications it is needed to call a function - dialoginfo_set for each INVITE which starts a dialog for which you want to have state published. This is better than the old way when the dialog publications were done for each dialog for which dialog_create function from dialog module was called. Modified Paths: -- trunk/modules/pua_dialoginfo/README trunk/modules/pua_dialoginfo/doc/pua_dialoginfo_admin.xml trunk/modules/pua_dialoginfo/pua_dialoginfo.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5835] trunk/modules/pua_dialoginfo
IƱaki Baz Castillo schrieb: 2009/7/7 Klaus Darilion klaus.mailingli...@pernau.at: Hi Anca! Nice feature, missing since long time :-) If I understand the code, this triggers PUBLISH with trying even if the dialog is not created (e.g. script error after dialoginfo_set()). In this case, it will stay in trying state for default lifetime. Wouldn't it be better to send trying also from a callback. PUBLISH dialog with trying state is in fact a NOOP and it's not useful at all from the watcher's perspective. I suggest never to publish it. Also, the proceeding state means that a 1xx with no To tag (this is, a 100) has been received. This is also not useful, so I wouldn't publish it. IMO it is useful - eg. A calls PSTN and the call setup takes long - e.g. 10 seconds until ringing. In this time intervall, A is already busy on the phone, thus other probably will get notified that A is currently on the phone and the will try to reach him later. regards klaus ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5091] trunk/modules
Anca Vamanu schrieb: Hi Klaus, I have changed pua_dialog info module not that much because of bugs but because of improvements in code. I have found a bug - when you retrieved the parameter in dialog callback. In file pua_dialoginfo.c at line 196 you have this: struct dlginfo_cell *dlginfo = (struct dlginfo_cell*)_params-param; But in fact you need to indirect this like this: struct dlginfo_cell *dlginfo = (struct dlginfo_cell*)(*_params-param); The reason for this is if you look in 'run_dlg_callbacks' function from modules/dialog/dlg_cb.c at line 251: params.param = cb-param; you can see that the param field of the structure retains the address of the parameter. However I have taken the parameter part all out because I consider that there is no need for it. I saw that in your comments you mentioned that you chose to copy the info in your structure and pass it as a parameter because: /* store the important data locally to avoid reading the data from the dlg_cell during the callback (as this could create a race condition if the dlg_cell gets meanwhile deleted) */ In fact there is no race condition as the dialog structure is locked while the callbacks are executed. Interesting: We had a discussion on the mailing list with the result that the data should be copied during the CREATE callback as the other callbacks are executed without lock, please see: http://lists.kamailio.org/pipermail/devel/2008-September/016112.html regards klaus Some other changes that I made are: - I have added the 'dialog' event to pua module from pua_dialoginfo module - I have added presence_server module parameter and taken out override_lifetime parameter. regards, Anca Klaus Darilion wrote: Anca Vamanu wrote: Revision: 5091 http://opensips.svn.sourceforge.net/opensips/?rev=5091view=rev Author: anca_vamanu Date: 2008-12-22 15:08:17 + (Mon, 22 Dec 2008) Log Message: --- - added modules pua_dialoginfo and presence_dialoginfo - they were imported from Kamailio( author Klaus Darilion), but suffered some modifications Hi Anca! I have troubles understanding your commit message. Have you modified the modules? If yes - did you found some bugs, or why? thanks klaus - the module implements the BLF feature described in RFC4235 - it has beed tested with snom 320 phones Added Paths: --- trunk/modules/presence_dialoginfo/ trunk/modules/presence_dialoginfo/Makefile trunk/modules/presence_dialoginfo/README trunk/modules/presence_dialoginfo/add_events.c trunk/modules/presence_dialoginfo/add_events.h trunk/modules/presence_dialoginfo/doc/ trunk/modules/presence_dialoginfo/doc/presence_dialoginfo.xml trunk/modules/presence_dialoginfo/doc/presence_dialoginfo_admin.xml trunk/modules/presence_dialoginfo/notify_body.c trunk/modules/presence_dialoginfo/notify_body.h trunk/modules/presence_dialoginfo/pidf.c trunk/modules/presence_dialoginfo/pidf.h trunk/modules/presence_dialoginfo/presence_dialoginfo.c trunk/modules/presence_dialoginfo/presence_dialoginfo.h trunk/modules/pua_dialoginfo/ trunk/modules/pua_dialoginfo/Makefile trunk/modules/pua_dialoginfo/README trunk/modules/pua_dialoginfo/dialog_publish.c trunk/modules/pua_dialoginfo/doc/ trunk/modules/pua_dialoginfo/doc/pua_dialoginfo.xml trunk/modules/pua_dialoginfo/doc/pua_dialoginfo_admin.xml trunk/modules/pua_dialoginfo/pua_dialoginfo.c trunk/modules/pua_dialoginfo/pua_dialoginfo.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Hang due to no more nonces can be generated
Bogdan-Andrei Iancu schrieb: Hi Inaki, It's sad, but the only reliable and always working solution to mantain a TCP connection through NAT is using short interval (32 sec) for registration. Am I wrong? I have to agree on this - TCP is not as simple as UDP - I mean, to keep the connection up, you need cooperation from both parties PD: please please... implement keep-alive for TCP in OpenSIPS :) you mean as the one per UDP ? just an idea I just had: I think reusing the UDP keep alive mechanism also on TCP is not a good idea (.e.g. if the TCP connection is lost ...). Maybe it could be possible to mark TCP connections as keep alive. Then there would be a dedicated TCP/TLS keepalive process which loops over all currently opened TCP connections and if it founds a TCP connection with the keep-alive flag it sends CRLF. just an idea klaus ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5037] trunk/modules/dialog/dlg_handlers.c
Hi Dan! Is this a bug fix? Are there issues with the old behavior? thanks Klaus Dan Pascu schrieb: Revision: 5037 http://opensips.svn.sourceforge.net/opensips/?rev=5037view=rev Author: dan_pascu Date: 2008-11-28 11:16:03 + (Fri, 28 Nov 2008) Log Message: --- Call dialog create callbacks after the dialog identity is established Modified Paths: -- trunk/modules/dialog/dlg_handlers.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] RFC: new opensips design
Bogdan-Andrei Iancu wrote: So DOS attack is not possible - at least not on this scenario :) I think DOS attacks are always possible - at least DDOS - unfortunately the bot networks out there are amazing ... ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel