There is one thing that should be fixed. The problem shows up if one account registers multiple times. We observed a scenario where a phone behind NAT did register, and with every new register the NAT assigned a different port to it. For some reason that phone sent multiple registration requests in a short interval (one explanation is that it may have been restarted multiple times during some experimentation with internal settings). Anyway, no matter the reason, the net result was that because every register request had a different source port, the device appeared to SER as multiple devices, and as a result there were multiple contacts stored in the subscribers table. After the number of registrations exceeded some value, SER started to complain that some buffer was exceeded and in the reply to the register requests it couldn't add all the contacts. Because the contacts were sorted in chronological order, the latest were missing. At this point the phone no longer saw its last contact in the reply and considered that it wasn't registered, while SER stored the contact in the subscribers table and considered the registration successful. From this point on, it entered into a spiraling process, the phone re-sending registration requests at every 5 seconds, resulting in 120 registrations in 10 minutes. One quick fix I think would be to return the contact list in reverse chronological order. This would guarantee that the phone will at least see it's latest contact and won't enter the spiral of sending register requests at every 5 seconds. A better fix (but probably more complex) would be to limit the number of allowed registrations for a given subscriber. That would also avoid issues with overflowing the contact list buffer in registration replies. Limiting the number of registrations allowed for a subscriber also makes sense considering that parallel forking can only be done to a limited number of contacts. On Thursday 30 June 2005 20:51, Daniel-Constantin Mierla wrote: -- Dan