6 Nov
2013
6 Nov
'13
7:28 p.m.
Hi,
I'm currently using the pcscf modules to build an IMS proxy. The
pcscf_is_registered() function uses the source IP, port and protocol to
search a record in the pcscf location database. In my case, I could
have to deal with several UACs using the same source IP and ports, so
this approach won't work for me.
The pcscf location database is indexed by the contact URI hash, so
is there a reason not to use the contact URI to do the lookup? Besides,
this should increase the performances when dealing with hundreds of
records (the ip/port/protocol lookup is linear).
Regards,
--
Camille
27 Nov
27 Nov
7:30 p.m.
Hi Camille,
i'll take a look at that.
I've implemented it that way in order to cope with NAT; however i can
probably simply replace it with the "add_contact_alias()" functions
from Nathelper...
Kind regards,
Carsten
2013/11/6 Camille Oudot <camille.oudot(a)orange.com>om>:
Hi,
I'm currently using the pcscf modules to build an IMS proxy. The
pcscf_is_registered() function uses the source IP, port and protocol to
search a record in the pcscf location database. In my case, I could
have to deal with several UACs using the same source IP and ports, so
this approach won't work for me.
The pcscf location database is indexed by the contact URI hash, so
is there a reason not to use the contact URI to do the lookup? Besides,
this should increase the performances when dealing with hundreds of
records (the ip/port/protocol lookup is linear).
Regards,
--
Camille
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 34927219
Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
9:30 p.m.
Le Wed, 27 Nov 2013 18:30:32 +0100,
Carsten Bock <carsten(a)ng-voice.com> a écrit :
Hi Carsten,
I've implemented it that way in order to cope with
NAT; however i can
probably simply replace it with the "add_contact_alias()" functions
from Nathelper...
so, maybe the pcscf_is_registered() function could:
* retrieve the pcontact record in O(1) using the Contact URI hash
[should pcscf_is_registered() fail if no there is no Contact
header? Could the Contact URI somehow change between REGISTER and
other requests?]
* compare the request's source ip & port with those stored in the
pcontact record
* if both steps succeed, return true
This should prevent performances issues if a lot of contacts are
registered. Besides, this would allow to differentiate several UACs
using the same network connection (as they very likely would provide
different contact URIs).
What do you think of this?
Cheers,
--
Camille
10 Dec
10 Dec
12:30 a.m.
Hi Camille,
i've changed it in GIT master to the following behaviour:
1) Lookup based on Contact
1a) compare Received-Info (IP, Port, Proto), if Contact was found
2) Fallback to the old behaviour (directly looking for IP, Port,
Proto) otherwise.
I've also changed the pcscf_assert_identity to do the lookup based on
the contact.
If you modify the INVITE for initial requests (e.g. use a
contact-alias "add_contact_alias()" for NAT-Traversal), you'll have to
apply the changes first before you can do the check. I've added a
warning, in case the lookup based on the contact fails.
I've tested the changes with CSipSimple, Snom phones and AVM FritzBox.
Kind regards,
Carsten
2013/11/27 Camille Oudot <camille.oudot(a)orange.com>om>:
Le Wed, 27 Nov 2013 18:30:32 +0100,
Carsten Bock <carsten(a)ng-voice.com> a écrit :
Hi Carsten,
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 34927219
Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
I've implemented it that way in order to cope
with NAT; however i can
probably simply replace it with the "add_contact_alias()" functions
from Nathelper...
so, maybe the pcscf_is_registered() function could:
* retrieve the pcontact record in O(1) using the Contact URI hash
[should pcscf_is_registered() fail if no there is no Contact
header? Could the Contact URI somehow change between REGISTER and
other requests?]
* compare the request's source ip & port with those stored in the
pcontact record
* if both steps succeed, return true
This should prevent performances issues if a lot of contacts are
registered. Besides, this would allow to differentiate several UACs
using the same network connection (as they very likely would provide
different contact URIs).
What do you think of this?
Cheers,
--
Camille
11 Dec
11 Dec
9:29 p.m.
Le Mon, 9 Dec 2013 23:30:44 +0100,
Carsten Bock <carsten(a)ng-voice.com> a écrit :
Hi Camille,
i've changed it in GIT master to the following behaviour:
1) Lookup based on Contact
1a) compare Received-Info (IP, Port, Proto), if Contact was found
2) Fallback to the old behaviour (directly looking for IP, Port,
Proto) otherwise.
Hi Carsten,
this looks nice, thanks. As Hugh Waite pointed, getContactP() always
fails (no fallback) when no Contact header is present, and would
prevent from using pcscf_is_registered() and pcscf_assert_identity() to
be used on Contact-less requests. For my use, this is not a problem,
and I see the fallback method as a potential way to make DoS attacks on
a P-CSCF, when a lot of contacts are registered, since id does a
sequential search, so I would rather not use it at all.
Maybe this fallback behavior should be made optional by configuration.
I'll add this when possible.
Cheers
--
Camille
16 Dec
16 Dec
12:12 p.m.
Hi Camille,
i've just made the fallback configurable (default: off) in git-master.
I will commit the change later.
Thanks & merry christmas,
Carsten
2013/12/11 Camille Oudot <camille.oudot(a)orange.com>om>:
Le Mon, 9 Dec 2013 23:30:44 +0100,
Carsten Bock <carsten(a)ng-voice.com> a écrit :
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 34927219
Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
Hi Camille,
i've changed it in GIT master to the following behaviour:
1) Lookup based on Contact
1a) compare Received-Info (IP, Port, Proto), if Contact was found
2) Fallback to the old behaviour (directly looking for IP, Port,
Proto) otherwise.
Hi Carsten,
this looks nice, thanks. As Hugh Waite pointed, getContactP() always
fails (no fallback) when no Contact header is present, and would
prevent from using pcscf_is_registered() and pcscf_assert_identity() to
be used on Contact-less requests. For my use, this is not a problem,
and I see the fallback method as a potential way to make DoS attacks on
a P-CSCF, when a lot of contacts are registered, since id does a
sequential search, so I would rather not use it at all.
Maybe this fallback behavior should be made optional by configuration.
I'll add this when possible.
Cheers
--
Camille
3994
days inactive
4034
days old
5 comments
2 participants
participants (2)
-
Camille Oudot -
Carsten Bock