Re: [Partysip-dev] problems: SFP-callbacks and mysterious delays

[Stefan Fritzsche]

> > Although I don't think that ethereal can measure time with such
> > an accuracy, I think about 500 ms are to much (for just a
> > question of optimization).
> > For me this looks like some kind of race-condition/multi-threading
> > problem or something like that.
> 
> I'll do my best to create the new branch with the new beta partysip
> version ASAP. It should be easier to resolve those issue with the
> new architecture.
>
> I'll keep you informed.

That sounds like your a little bit annoyed.
(Sorry, that wasn't my intention.)

However, it took me a couple of time to debug
partysip, and to recognize were the delay comes
from (in the 2.0.1-version).

It comes from "osip_timers_thread()" in "psp_osip.c".
There you have a select waiting max. psp_osip->delay*1000
micro-seconds. I suppose the forwarded 200-ok (or ringing)
gets not send, because the osip-module was waken up, but
because the select-timer fires. (the origin of the delay)

I think there is somewhere a "psp_osip_wakeup(core->psp_osip);"
missing after forwarding the 200-ok (in the sfp-module). 
Thus I added it at the end of "pspm_sfp_execute()" right
after your "psp_core_unlock();".

The result is, that osip-module will be waken up every time
when sfp-module was executed. Actually this is not necessary,
because it would be sufficient to wake up osip-module only 
after a message has been forwarded, but it works.

Now the 200-ok- and ringing-messages get forwarded as fast
as the other ones.


Best regards,
Stefan Fritzsche

-- 
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! +++