Re: [Partysip-dev] several questions

[Aymeric Moizard]

On Tue, 11 Nov 2003, Stefan Fritzsche wrote:

> Hello Aymeric,
>
> I have some questions, as usual.
>
> I have problems understanding the partysip-architecture:
>
>   1) Why does partysip use Multithreading?
>       Some time ago you mentioned that callbacks are
>       protected by mutexes, so that they can't be
>       executed parallel. So I don't see any advantage
>       using different threads for each module.

The only place where multithread is requierd is for
the DNS resolver.

Otherwise, there is not many advantage.

>   2) Why is the "record-route"-feature not integrated
>       in the partysip-core or sfp-module? Having this
>       feature spread over different plugins is really
>       confusing.

For some call, you may want some calls to be record-routed
and some other to not be. This is not user-freindly, but this
is very usefull. For example it's a bad idea to handle local
et remote user with the same rules for record-routing.

> Furthermore there are some implementation specific points:
>
>   3) Giving each plugin the option to "mandate" a
>       request is confusing and makes it hard to write
>       additional plugins.
>       I think it would be better to let all plugins do their
>       job, and collect each plugin's opinion, whether the
>       request could be processed success-fully or not.
>       Additionally each plugin should have access to all
>       status returned by other plugins before.

This might be a good idea, (and the PROPOSE word was added there
to start implementing such feature). I finally did not find it
easy and very helpfull to finish it.

>       E.g. this would make it much easier to let a plugin
>       perform a specific task, if the callee of an Invite is
>       available. Currently this is not possible, because
>       the localdb-plugin mandates requests if a location
>       is found.
>       This particular problem is really anoying ... if localdb
>       finds a location, following callbacks will no be processed,
>       and if you place your new callback before localdb's
>       callback, you do not know if the callee of an Invite is
>       available :-(
>
>       Such a problem also occurs if one tries to catch
>       Re-Invites (e.g. of a three-way-conference), because
>       the filter-plugin mandates requests if there is a psp-tag
>       in the route-header.
>       Therefore I've added my own sfp-inc-callbacks, which
>       are called after each other sfp-inc-callback, even when
>       the request get's mandated before. So if one defines a
>       callback, as PSP_HOOK_FINAL one can catch INVITES
>       after localdb found a location and catch Re-INVITES
>       after filter-plugin mandated it.
>       (I would please you to take a look at the patch in the
>        attachment and let me know if this breaks some
>        important things in partysip, that I didn't notice)

I did not already looked at your patch, but I understand your
concern.

Partysip has been done primarly to route request. Therefore,
it's useless to pass all plugins when the routing information
is complete (if the psp-tag is found, there is no reason to
look in the local_db).

Of course, this might be seen as a limitation if you want partysip
to do some other task on messages.

I would finally say that your logic is not better than mine :)
It's just a different view for probably different needs and of
course it would be great to improve partysip so evry kind of logic
needed would be possible in partysip.

To acheive this, it would be great to improve the plugin mangament
in partysip: instead of loading plugins, a better way would be to
build tiny script where tests/decision on message can be done with method
provided by plugins.

if (psp_tag_exist(message))
  {
    forward_request(message);
    exit();
  }

if (filter_match(message, "tel:12334"))
 {
   filter_forward_request(message, "sip:address@hidden");
   exit();
 }

...

It think the above solution is where partysip should go.. But it
would require a lot of work...

I'll take a look at your patch and will try to see if I can merge
it without breaking all my plugins!

> Well ... that's all.
>
> I'm feeling better now.

Good! Thanks for your work and feedback.
Aymeric

> (It's like in front of a self-help-group when taking the courage
> to tell 'em all my problems, seeing them nodding their heads
> and silently clapping after I finished disclosing my soul ...)
>
>
> Best regards,
> Stefan Fritzsche
>
> PS: the patch shows the differences to the "branch_2_1_X"-
> version of partysip. It also corrects a bug in psp_core2.c
> line 88, which appended REALLY_LAST-sfp-inc-hooks to
> the LAST-callback-list.
> (to apply patch: patch -p0 < "the-patch"
>  from outside of the partysip-top-dir)
>
>
> --
> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
>
> Jetzt kostenlos anmelden unter http://www.gmx.net
>
> +++ GMX - die erste Adresse für Mail, Message, More! +++