[Serusers] http / https in Userloc db

[Jan Janak]

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.