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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers