2 Mar
2005
2 Mar
'05
2:04 p.m.
Hi Jan,
So some URI checking is required and indeed, if you want to allow
clients to perform that magic you mentioned, the checking should be done
after extracting the URIs from usrloc.
But should be very clear if a contact URI can or cannot be involved in
SIP signaling - used for forwarding. One note here - it's interesting
what will be the impact on nathelper when it will start doing NAT ping
to non-SIP URIs :-).
Anyhow, the best place to do the checking is before t_relay(). If you do
th filtering immediately after lookup(), you will loose the Redirect
Server functionality.
Best regards,
Marian
Jan Janak wrote:
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.
>>
--
Voice System
http://www.voice-system.ro