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
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. -- Iñaki Baz Castillo i...@aliax.net ___ 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:[5835] trunk/modules/pua_dialoginfo
2009/7/7 Klaus Darilion klaus.mailingli...@pernau.at: 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. Othe example: - A is subscribed to dialog presence of C. - B calls C. - The proxy generates a dialog trying PUBLISH (C is called) and sends it to A. - A sees in his phone that C is begin called by B. - However, due to some network error (or C crashed) C doesn't reply to the INVITE (neither 100 or 1XX). In this case, why is useful the NOTIFY A has received? Or perhaps the trying and preceeding NOTIFY would only be received by A in case C is the caller? -- Iñaki Baz Castillo i...@aliax.net ___ 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
El Martes, 7 de Julio de 2009, Adrian Georgescu escribió: Inaki, Should the dialog timeout in this case? Sorry, what do you mean? I couldn't understand. -- Iñaki Baz Castillo i...@aliax.net ___ 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
El Martes, 7 de Julio de 2009, Adrian Georgescu escribió: When a dialog times out, other actions can be triggered like updating the state for event dialog. Same as we can send BYE messages. Ok, but in case C crashed, why is useful A receiving a NOTIFY trying telling that C is receiving a call? (even if the notification would be terminated when the dialog or INVITE transactions times out). -- Iñaki Baz Castillo i...@aliax.net ___ 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
Even if it did crash, the purpose of the module is to notify an interested party when someone will likely be engaged in a phone call. If the end-point of the monitored party crashed just before an INVITE will be sent to it this does not affect anything related to the purpose of the dialog Event. I do not see a conflict here, do you? Adrian On Jul 7, 2009, at 10:34 PM, Iñaki Baz Castillo wrote: El Martes, 7 de Julio de 2009, Adrian Georgescu escribió: When a dialog times out, other actions can be triggered like updating the state for event dialog. Same as we can send BYE messages. Ok, but in case C crashed, why is useful A receiving a NOTIFY trying telling that C is receiving a call? (even if the notification would be terminated when the dialog or INVITE transactions times out). -- Iñaki Baz Castillo i...@aliax.net ___ 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
