On Wed, May 10, 2006 at 03:24:51PM +0100, Miguel Freitas wrote:
It is no problem if you have in config file something like this:
if (method=="SUBSCRIBE") { ... if (@to.tag=="") { ... } else { if (!handle_rls_subscription("0")) { lookup_user("To"); handle_subscription("registrar"); } }This means that SUBSCRIBE requests with nonempty to tag (renewal subscriptions) are handled by RLS module first and if it fails (for example the subscription doesn't exist) it is handled by PA. In the case of unexisting resource list subscription it shows this warning.
I was missing line lookup_user("To");
It was missing in the presence handbook too - it will be corrected in next version.
Shouldn't the resource list of subscriptions be stored on the SER DB? Because I'm getting that Waning all the time and I can't find any entry related with subscriptions (table rls_subscription, ...)
No DB is not problem there. I will correct it in CVS - this warning will not be displayed if parameter will be "0".
Could you send network dump of such messages?
I have captured SIP and HTTP packets with Ethereal, sending file.. (It doesn't include packets changed between SER and apache because they are on the same machine and I don't have access to it right now) SER and apache on 193.136.93.140 SIP domain = itav140.av.it.pt eyeBeam sip:4004@193.136.93.252 and <sip:4002@193.136.92.68 > After register, client <sip:4002@193.136.92.68 sip:4002@193.136.92.68> changes his status to Away (packet 53) sip:4004 receives the new presence status of sip:4002 (packet 55 and 75) But when sip:4002 renew his PUBLISH (packet 79) he doesn't include a message body with his presence state. So, the subsequent NOTIFY received by sip:4004 (packet 85) doesn't include the presence status Away any more, even thou sip:4002 hasn't changed his status. After that, the client sip:4004 shows sip:4002 as Available, when he is Away.
Bingo! You have found a bug in SER - thanks! I have read it in RFC now, and in the case of empty body needs the state be refreshed, not cleared as was done. I will correct it soon.
Vaclav