On 02-03 23:28, Martin Koenig wrote:
Hi,
Nils, you are very correct :)
As a result of the discussion, I'd suggest implementing an Usrloc configuration parameter to enable ignoration of non sip URIs on save("location"). My guess is that the vast majority of all users does not need any other form of contact in their usrloc db than sip. Those that need it for redirection servers could enable it by configuration parameter.
I would dare to disagree. Solving this problem outside usrloc is in my opinion better.
The huge advantage of such solution would be that a "clean" usrloc database for all other ser modules (nathelper, mediaproxy, who knows what else) could be implemented by just one change to the usrloc module.
What constitutes a "clean" usrloc database ? Is it just sip uris ? Should tel uris be included ? How about sips, pres which are widely used in existing RFCs and drafts ?
RFC3261 says that the registrar must either process all contacts in a REGISTER message or refuse all of them. To be compliant, shall we reject all REGISTER messages that include "unclean" contacts ?
As you can see there are many open questions and ignoring just http uris would be not enough.
I am not really sure that all errors and itches caused by non-sip contacts in usrloc result only in a syslog error, maybe rather unpredictable behaviour might be the case (e.g. buffer problems)?
Do you have any particular problem in mind ?
Also, I don't think that a ser setup with this restriction would be called non-RFC3261 compilant? What do you guys think?
If you want to be really strictly compliant, then you would need to reject a REGISTER message that contains a Contact which your proxy is not willing to process. If such a REGISTER message does not get rejected than even contacts having http scheme in URI must be included in 200 OK. In this case the UA would assume that the contact is stored in the user location database.
Jan.