8 Mar
2005
8 Mar
'05
2:35 p.m.
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.