Hello Anca With the current release 2993 this works. In general I use no etag param. I know what you mean by that it changes (for re-updates initiated by PUA, last numbers change e.g. from 1.0 to 2.1). I have now a different error though, even worse: First sending publish with infinite Expires: -1 works, also Expires: 0 afterwards deletes the entry in the presentity table (works as well). But if I wanna do another publish after this scenario, the whole OpenSER PUA gets stuck. It doesn't accept anymore MI publication. Also DEBUG log stops. The last lines I see in the debug are DBG:pua_mi:mi_pua_publish: send publish DPG: pua:send_publish: pres_uri=test(a)10.96.115.125 And then it freezes, no more debug information and MI request acceptance (also no reply in MI output FIFO) SIP messagesd for first publishs with Expires: -1 and 0 are exchanged (Publish/200 OK and Publish/200 OK) but for sending a Expires: -1 request again, no SIP message is created as well. What can be the error here? Stange it works once but afterwards not. Can it be that Expires: 0 deletes the presentity table entry but pua table entry is still there? I tried as well to delete that one manually before performing second publish with Expires: -1 but it doesn't work either. Regards Sebastian -----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Monday, October 29, 2007 4:04 PM To: Schumann Sebastian Cc: users(a)openser.org; devel(a)openser.org Subject: Re: [OpenSER-Devel] PUA/PUA_MI Error: Hello, If you set the etag parameter when sending the "Expires: 0 " command, it might be that it is no longer valid. This happens if you first give a command with Expires value grater than the maximum accepted value by presence module. Then, the pua will generate itself updates such that the cumulated period of validity to equal the Expires in the first request. And for each new publish a different etag is replied.This is especially true if you have previously used an Expires: -1. On the other hand, if you do not set the etag param, there was a bug in the hash table searching function that was fixed in version 2993, that applied for the commands with no etag. Have you tested with this version? regards, Anca Vamanu Schumann Sebastian wrote: consistencies. ------------------------------------------------------------------------