7 Sep
2007
7 Sep
'07
1:37 p.m.
Hi,
sorry but what matter the content in Contact header, admitting that it
is a valid URI??
The CPE can be behind nat and do not have the same parameters of the
registration to be reached.
I think the problem is to ensure that the From and To that form the AOR
that the client is about to register is allowed
for that client.
In my config i have multiple numbers that can be assigned to a single
CPE and i use AVP to check that username used is
allowed to register that AOR.
If i'm not wrong the contact is posted in the INVITE after the lookup of
the AOR on the proxy, so you cannot receive
calls of some one else if you check the authentication correspond to AOR
enabled to register with that authentication.
Another issue is that some crap phones put URI not valid in the contact
like:
http://x.x.x.x
https:/x.x.x.x
Or something like this.
There is a way to check the validity of the URI before allow the
registration??
Thanks,
Bye,
Marcello
Daniel-Constantin Mierla wrote:
On 09/06/07 15:40, Christian Schlatter wrote:
Klaus Darilion wrote:
indeed, to make everybody
happy, the solution is provided by
uri_db/check_from(), as stated in this thread. By that, any user can
set a list of other users that can do registrations in its behalf,
that's uri table for.
Daniel
>
> /Christian
>
>
>>
>> After authentication, use check_to() for REGISTER and check_from()
>> for all other SIP requests.
>>
>> regards
>> klaus
>>
>> Marc LEURENT schrieb:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I have a security matter with my configuration (default one), it's
>>> possible to register using login/password and to set anything in
>>> the contact field.
>>> So if you have an account 106/password, it's possible to be 105 in
>>> the location database!
>>>
>>> How is it possible to deny that kind of matter..? Thanks
>>>
>>> Is it useful to use: method_filtering of the REGISTRAR module
>>> Or is it better to so something whith the values below and a
>>> compare function??
>>> $ct - reference to body of contact header
>>> $ar - realm from Authorization or Proxy-Authorization header
>>> $au - username from Authorization or Proxy-Authorization header
>>>
>>> if ($ct != $au@$ar) {
>>> sl_send_reply("403", "User and login must be the
same");
>>> };
>>>
>>> Best Regards,
>>>
>>> Marc LEURENT
>>> This is an old problem - often called
registration hijacking.
Some call it a feature: 3rd party registration ;-)