The error message is not issued by lookup("location"), it is issued by
t_relay() when you try to forward the message to the HTTP URI.
It should be easy to write a function that would be called before
t_relay (or after lookup) and that would filter out URI schemes
unsupported by SER.
For the Request-URI you can do that from the script:
if (uri =~ "^http") {
do something
};
But that would not check additional branches used for parallel forking.
Jan.
On 02-03 13:08, Martin Koenig wrote:
Jan,
if any uri (according to RFC) is allowed in URI, then ser should not
issue an error message on lookup("location"):
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0
parsed: <http> (4) / <http://192.168.0.206:80> (23)
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri:
http://192.168.0.206:80
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0
parsed: <http> (4) / <https://192.168.0.206:443> (25)
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri:
https://192.168.0.206:443
Especially not a "bad_uri" error message, because it is not a bad uri
indeed. Some debug-warning about ignoring this or that contact because
it was not SIP/SIPS will do. What do you think?
Either way, I think there is need for some cleanup.
Regards,
Martin
Jan Janak schrieb:
On 02-03 10:32, Marian Dumitru wrote:
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it
advertise the http location of the web configuration page. But if recall
correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact
validity before inserting into usrloc.
That's one interesting question. What is a valid contact ? A regular
proxy would not be able to contact URI with http scheme, that's clear.
But that does not mean yet that the contact is not valid, because
RFC3261 allows any sort of URI to appear there.
On the other hand, a redirect server would just take this URI, put it
into a 3xx response and send it back the the calling UA. If the calling
UA is unable to reach the called party, it might display the contents
of the HTTP URL or do some other magic.
For that reason I think that there should be no limitation of what
gets into the user location database.
Jan.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers