Hi Dan,

For this purpose, you have to parameter for the register module: desc_time_order = "If set to 1 then all contacts will be ordered in descending modification time order. In this case the most recently updated/created contact will be used." max_contacts = " The parameter can be used to limit the number of contacts per AOR (Address of Record) in the user location database. Value 0 disables the check."

the description id copied from web doc: http://www.openser.org/docs/modules/0.9.x/registrar.html

regards, bogdan

Dan Pascu wrote:

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:

...

Hello,

the roadmap to the next release is now posted online: http://openser.org/roadmap.php

Time lines are just estimations and could be subject to change, other features may be added to the next release. If you have in mind other features, send a reply and describe what would be good to have in the next release.

Comments are welcome!

On 07/03/05 22:23, Juha Heinanen wrote:

i would say that native tcp/ip access to ser instead of fifo or sockets should be high priority, because otherwise management server must run on the sip proxy host which makes no sense.

Yes, it is a priority, but will require a lot of changes and development. Once the CVS head will be branched and labeled as testing, will start the design and development of this part, otherwise next release would be delayed too much.

Daniel

currently the only way to achieve remote access is fifo relay that i wrote as a hack.

-- juha